Стандарти, що регламентують документування програмних проектів
Общие требования к составу и содержанию документов, поддерживающих создание ПС, представлены в ряде стандартов разного ранга, в фирменных описаниях технологий и в публикациях по управлению проектами. Состав и формы документов широко варьируется в зависимости от класса и характеристик объекта разработки, а также в зависимости от используемой технологии. Наиболее сложному случаю разработки критических ПС высокого качества, соответствует представленная широкая номенклатура документов. Такой перечень документов может быть использован как базовый для формирования из него состава документов в остальных более простых случаях. Стандарт ISO 9294 представляет руководство по документированию ПС для менеджеров, отвечающих за создание программных продуктов. Руководство предназначено для помощи в управлении разработкой и эффективном документировании программных проектов. Стандарт содержит рекомендуемые стратегии, процедуры, ресурсы и планы, которыми должны заниматься руководители проектов в целях эффективного создания комплектов документов ПС. Общая структура стандарта представлена на рисунке 1.
Рисунок 1
Руководители проектов ПС должны осуществлять организацию работ по документированию и поддержку этих работ в планах, которыми они определяются. Для этого требуется руководство и стимулирование персонала при проведении требуемого документирования и обеспечение его ресурсами в этих работах. Специалистам необходимо обеспечить: опубликованные официальные отчеты о стратегии документирования; стандарты и руководства определяющие все аспекты процессов документирования; выделение соответствующих ресурсов на документирование; планирование документирования, осуществляемое как неотъемлемая часть процесса разработки программного средства. Во время разработки ПС администрации необходимо оценивать ход работы, возникающие проблемы и развитие процесса документирования. Периодические стандартизированные отчеты, согласно которым проверяется ход работ по графику и представляются планы на следующий период, должны обеспечивать контроль и обзор развития проекта. Этим специалистам необходимы средства общения с друг с другом, обеспечивающие информацию, которую можно, при необходимости, воспроизводить, распространять и на которые можно ссылаться. Большинство методологий разработки ПС устанавливают официальные документы для связи между задачами о специалистами. для обеспечения качества ПС требуется документация процессов разработки и документация продукции. Сопровождающим специалистам и программистам требуется детальное описание ПС, такое, чтобы они могли локализовать и корректировать дефекты, модернизировать и изменять программы. Стратегии документирования, подготовленные и отслеживаемые администрацией проекта, должны обеспечивать документы я ответственных лиц, принимающих решения на всех нижних уровнях. Из-за существенной роли, которую играет документация на всех этапах жизненного цикла ПС, должна быть подготовлена официально утвержденная стратегия. Каждый специалист, затронутый стратегией, должен быть информирован о ней и должен ее понимать. Официальная, описанная, разрекламированная стратегия устанавливает дисциплину, требуемую для эффективного документирования ПС. Стратегия должна поддерживать основные элементы эффективного документирования, требования документации должны охватывать весь жизненный цикл ПС. Руководители и специалисты по изданиям должны ГОТОВИТЬ шаблоны документов, подробные планы, охватывающие документирование продукции, графики, обязанности, ресурсы, обеспечение качества и процедуры проверок. Читателями документов могут быть руководители, аналитики, специалисты по экспертным системам, сопровождающие программисты, канцелярский персонал. В зависимости от выполняемых задач им требуются различные степени детализации и различное представление материала. Специалисты по изданиям должны быть готовы соответствующим образом спроектировать различные типы шаблонов документации, предназначенные для различных читателей. Внутри предприятия должны быть приняты стандарты а руководства для: - модели жизненного цикла ПС; - типов и взаимосвязей документов; - содержания и шаблонов документов; - качества документов; - форматов и обозначения шаблонов документов. Такие стандарты и руководства должны определять, как следует выполнять задачи документирования, обеспечивать критерии для оценки полноты, полезности и соответствия документации программному продукту. По возможности, должны быть использованы действующие международные и национальные стандарты. Зачастую могут требоваться управленческие решения для адаптации общих рекомендаций этих стандартов к конкретным проектам. Контракт с заказчиком должен требовать, чтобы документация удовлетворяла принятым стандартам. Он должен определять типы поставляемых документов, уровень качества каждого и процедуры их проверки и утверждения. Руководители должны, выбрать соответствующую модель ЖЦ ПС и гарантировать, чтобы ее применяли в данном предприятии. Создание документации, связанной с конкретным этапом, может быть использовано как контрольный пункт для проверки, приемки и завершения этапа работ. Программные документы в данном стандарте предлагается представить разделенными на три категории: - документация разработки; - документация продукции; - документация управления проектом. Документация разработки (технологическая) описывает процесс разработки определяет требования, которым должно удовлетворить ПС, определяет проект, как его контролируют и обеспечивают качество. Документация разработки включает подробное техническое описание ПС (программную логику, взаимосвязи, форматы хранение данных). Она является средством связи между всеми лицами, вовлеченными в процесс разработки, описывает подробности решений принятых относительно требований к ПС, проекту, программированию и тестированию, а также обязанности группы разработки — кто, что и когда делает, учитывая роль объекта работ, документации, персонала, обеспечивающего качество, и каждого специалиста в процессе разработки. Документация образует основу сопровождения — описывает историю разработки ПС. Если документы разработки отсутствуют, неполны или устарели, руководители теряют важное средство для отслеживания и контроля проекта. Документация продукции (эксплуатационная) обеспечивает формацию, необходимую для эксплуатации, сопровождения модернизации, преобразования и передачи программной продукции к пользователю. Она обеспечивает учебную и справочную информацию для специалистов использующих или эксплуатирующих программную продукцию; облегчает программистам не разрабатывающим ПС, его сопровождение и модернизацию; помогает продаже приемке программной продукции. Документация продукции, должна включать материалы: для пользователей, которые вводят данные, восстанавливают информацию и решают задачи с помощью ПС для операторов, которые применяют и ПС на вычислительной системе; для сопровождающих программистов, а также материалы для руководителей которые следят за использованием комплекса программ. Типовые документы продукции включают: учебные руководства; справочные руководства и руководства пользователей; руководства по сопровождению ПС; брошюры и информационные листовки, посвященные рекламе продукции. Документация управления проектом включает графики для каждой стадии процесса разработки и отчеты об изменениях графиков; отчеты о согласованных изменениях программ; отчеты о решениях, связанных с разработкой; распределение обязанностей специалистов. Руководители должны применять стандарты, распространяющиеся на обеспечение качества, соответственно различными типами документов и различным типам проектов, и должны определять, как это качество будет достигнуто и поддержано. Понятия качества документации включает: качество содержания; структуру информации; представление проекта с иллюстрациями. Стандартизированные форматы — шаблоны документов важны для контроля качества документов, для читаемости документов и для облегчения их сопровождения. Форматы документов могут различаться от проекта к проекту. Они зависят от таких факторов, как объем проекта, аудитория, для которой предназначены документы, количество установленных стадий и бюджет документирования. В проектируемых форматах должно быть учтено будут ли документы переводиться для международного распространения. Стандартные обозначения документов необходимы для эффективного контроля документации. Обозначающая информация может включать в себя: заглавие документа; номер версии документа; дату выпуска и пересмотра; реквизиты автора; реквизиты утвердившего лица; обозначение защищенности (авторских прав); обозначение предприятия. должны быть установлены процедуры для применяемых стратегий: - последовательность документирования; - планирование; - конфигурационное управление; - проверки; - утверждение; - производство; - хранение; - дублирование; - распространение и модернизация; - продажа. Процедуры также должны определять контрольные пункты и методы обеспечения качества. Основными ресурсами в стандарте, для документирования выделяются: персонал; инструментальные средства; финансирование. для процесса разработки необходимы люди со знанием: программирования; сути предмета применения ПС; документирования продукции. Важно, чтобы штат был полностью обучен методам документирования, и чтобы каждая группа специалистов полностью понимала и выполняла свою роль в процессе документирования. Проектировщики ПС и программисты создают документацию разработки; специалисты в предметной области обеспечивают информацию для стадий изучения спецификаций требований, планов тестирования и обеспечения качества, планов сборки программ. Специалисты по изданию обычно подготовляют документацию по обучению пользователей, а также справочную и информационную о продукции. Важно предусмотреть обеспечение задач документирования соответствующими техническими средствами. Они могут быть применены для повышения эффективности многих процессов документирования и использования стандартов данного предприятия распространяющихся на документирование. Полезно, чтобы стоимость документирования определяли как отдельные статьи бюджета, так как она нередко составляет значительную часть стоимости разработки ПС. План документирования определяет, что должно быть сделан, как, когда и кто это должен делать. Для больших проектов это может быть объемный документ, который следует установленным стандартам и является предметом для официальной проверки и процедуры утверждения. План документирования должен быть доведен до всех участников разрабатывающего коллектива, кого он касается. Должны быть четко установлены обязанности всех вовлеченных в работу, связанную с документированием. График документирования должен распределять время для: планирования разработки документов; проверки плана и принципов документирования; подготовки проектов и проверки их на техническую точность, полноту и соответствие; проведение согласования; распространения. Планирование следует начинать заранее, реализацию плана необходимо проверять на всем протяжении проекта. План документирования отражает намечаемые действия и является объектом для необходимых изменений. В проекте должны быть предусмотрены регулярные проверки результативности изменений в плане. Стандарт ISO 12182 — описывает схему классификации программных средств, охватывающую существенные характеристики и атрибуты, отражающие и определяющие ПС, их виды и классы. установленная в стандарте классификация предназначена для определения классов конкретных ПС, и связей программных задач, процессов или продуктов и их документов со стандартами программной инженерии. В настоящем стандарте установлена схема классификации, помогающая: - уточнить области применения используемого стандарта или ПС; - определить, выбрать стандарты и шаблоны документов, применимые к конкретному проекту ПС; - определить классификационные характеристики новых стандартов. Описанная в настоящем стандарте классификация может служить в качестве концептуальной схемы построения системы документации. Разработчики и заказчики должны применять собственные подходы к использованию данной классификации. Ее описание не основано на четко установленных потребностях разработчиков и пользователей, поэтому применение данной схемы в практической деятельности не является обязательным. Схема классификации состоит из 16 видов, которые объединены в следующие группы. Внутренние виды: - режим эксплуатации; - масштаб ПС; - стабильность ПС; - функциональные возможности; функции ПС; - требование защиты; - требование надежности; - требуемые рабочие характеристики; - исходный язык. Виды среды: - прикладная область информационной системы; - вычислительная система и среда; - класс пользователя; - требование к вычислительным ресурсам; - критичность ПС; - готовность программного продукта. Виды данных: - представление данных; - использование программных данных. для классификации конкретного ПС может быть достаточен один вид или выбранный набор видов с конкретными классами. В зависимости от специфики ПС может быть необходимым использование дополнительных видов. В ряде случаев применения схемы классификации для представления наиболее специфичных характеристик и документации ПС может быть использована комбинация нескольких видов с конкретными классами. Схема классификации, связанная с описанием каждого вида, представляет собой перечень классов, соответствующих данному виду. В большинстве случаев такие перечни являются типовыми или открытыми, а не исчерпывающими или полными. Пользователи схемы классификации должен и руководствоваться собственными соображениями при выборе и идентификации соответствующих классов для конкретного ПС или прикладной области. Примерами классов функции ПС являются: - обработка деловых сообщений; - компиляция; - научные вычисления; - обработка текстов; - медицинские системы; - системы управления объектами или процессами. Для вида прикладная областисистемы, классы должны быть определены в зависимости от типа или класса внешней среды и системы, в которой они устанавливаются. Примерами классов прикладной области являются: - наука; - бытовые устройства; - оборудование - аппаратура управления объектом или процессом - предпринимательство - система организации сети. Для вида режим эксплуатации классы должны быть определены в зависимости от конкретных технологий или типов обработки, принятых в системе: - пакетная обработка данных; - обработка данных в режиме реального времени; - обработка данных в режиме разделения времени; - параллельная обработка данных; - совмещенная обработка данных. Для вида масштаб ПС должны быть определены классы в зависимости от размера или сложности ПС. Размер может быть определен в числа строк исходной программы (SLOC), исключая комментарии, и уточнен на уровне языка (в Ассемблере, Фортране, Аде). Сложность может быть определена как функция соответствующего параметра, классов масштаба ПС: - малый; - средний; - большой. Следует учитывать, что диапазоны выше названных классов не должны быть жесткими. Напротив, классы должны быть установлены с учетом представления неопределенных или приблизительных диапазонов. В остальные 12 видов характеристик, которые в стандарте иллюстрируются примерами классов, выделены: - представление данных; - исходный язык; - критичность ПС; - класс пользователя; - стабильность ПС; - готовность программного продукта; - использование программных данных; - требуемые рабочие характеристики; - требование защиты; - требование надежности; - вычислительная система и среда; - требование к вычислительным ресурсам. Применение стандарта иллюстрируется таблицей взаимосвязи шести характеристик качества ПС по стандарту ISO 9126 и 16-ти видов классификации комплексов программ в области действия стандарта ISO 12182. В стандарте ISO 12207 документированию посвящен специальный раздел 6.1 в группе вспомогательных процессов. Кроме того, почти все процессы и работы основного, пятого раздела стандарта, представляющего этапы и работы жизненного цикла ПС, отражают конкретные требования к документированию соответствующих работ. Специальный раздел стандарта по документированию ПС имеет следующее содержание (с небольшими сокращениями нумерации). Процесс документирования – это процесс для записи информации, произведенной процессами жизненного цикла. Процесс содержит набор действий, которые планируют, проектируют, разрабатывают, производят, редактируют, распределяют и сопровождают те документы, в которых нуждаются все заинтересованные лица проекта, такие как менеджеры, инженеры и пользователи системы или программного продукта. Реализация процесса — должен быть разработан, документирован и реализован план, идентифицирующий документы, которые должны быть произведены в течение жизненного цикла программного продукта. Для каждого идентифицированного документа должно быть определено следующее: заглавие (титул) или название; цель; предназначенная аудитория; процедуры и обязательства для вводов, разработки, обзора, модификации, утверждения, производства, хранения, распределения, сопровождения и управления конфигурацией; план, режим, программа для промежуточных и конечных (заключительных) версий. Проектирование и разработка — каждый идентифицированный документ должен быть спроектирован (разработан) согласно соответствующим документационным стандартам для формата — шаблона, описания содержания, нумерации страниц, размещения рисунков / таблиц, маркировки (отметки) права собственности/ защиты и других компонентов представления. Должны быть подтверждены источники и соответствие входных данных для документов. Подготовленные документы должны быть рассмотрены и отредактированы на предмет формата, технического содержания и стиля представления в соответствии с их стандартами. Они должны быть рассмотрены на соответствие и одобрены доверенным персоналом до выпуска. Производство — документы должны быть произведены и поставлены заказчику согласно плану. Производство и дистрибуция документов может использовать бумагу, электронные или другие средства. Оригинальный материал (оригинал) должен быть сохранен согласно требованиям для хранения данных, защиты, содержания и дублирования. Средства управления должны быть поставлены согласно процессу управления конфигурацией (раздел 6.2 стандарта ISO 12207). Сопровождение задач и, требующие исполнения измененного кода, представленного в документации, должны быть выполнены в соответствии с Процессами Сопровождения (см. раздел 5.5 стандарта). Для тех документов, которые находятся под конфигурационным управлением, модификации должны управляться согласно Процессу управления конфигурацией. Стандарт ГОСТ Р 51904 регламентирует документы, которые создаются в течение всего жизненного цикла ПС. Эти документы позволяют реализовать процессы и модификацию программного средства. Заказчик должен осуществлять выбор необходимого и экономически обоснованного Состава и Содержания документов для конкретной разработки, Заказчик разрешает любые конфликты между требованиями разрабатывающего предприятия и требованиями контракта. В настоящем стандарте не ставилась задача описать все документы, которые могут быть необходимы для разработки конкретного программного средства, и предложить конкретные методы организации информации. Дополнительно к З9-и документам, определяемым в этом стандарте, могут быть подготовлены другие документы для поддержки процесса разработки и удовлетворения требований контракта. В отдельном разделе обсуждаются характеристики, форма, методы контроля конфигурации и содержание документов жизненного цикла ПС, при этом выделены: - однозначность: информация является однозначной, если она написана в терминах, которые допускают только единственную интерпретацию, уточненную, если необходимо, соответствующими определениями; - полнота: информация является полной, если она включает в себя необходимые требования и/или описательные материалы, определяет ответную реакцию для всего диапазона допустимых входных данных, используемые рисунки и таблицы сопровождаются необходимыми обозначениями, термины и единицы измерения определены; - верифицируемость: информация является верифицируемой, если она может быть проверена на корректность человеком или инструментальным средством; - согласованность: информация является согласованной, если не существует противоречий внутри нее и с внешней средой; - модифицируемость: информация является модифицируемой, если она структурирована и имеет такой стиль, что изменения могут быть выполнены в необходимом объеме, согласованно и корректно без нарушения структуры компонента или проекта ПС; - трассируемость: информация является трассируемой, если о каждого его компонента может быть определен корректный первоисточник. Форма документов должна обеспечивать эффективный поиск и просмотр документов ПС в процессе обслуживания систем. Состав документов и их конкретная форма должны быть определены в Плане. Документы жизненного цикла ПС могут быть отнесены к одной из двух категорий степени контроля, в соответствии с применяемыми в стандарте методами управления конфигурацией. Введение различных категорий контроля позволяет снизить стоимость разработки в случаях, когда менее строгий контроль может быть применен без снижения допустимого качества и безопасности. Кроме стандартов, приведенных в данном разделе, процессы документирования и рекомендуемая Структура шаблонов документов отражены, в той или иной степени, во многих стандартах.
|
