Формування вимог до документаціїМасштаб проектов комплексов и компонентов программ является одним из важнейших факторов, влияющим на формирование, структуры и содержание документации, поддерживающей весь жизненный цикл ПС. Оценки масштаба проекта ПС должны быть проанализированы и скорректированы для установления в договоре между заказчиками и разработчиками исходного компромиссного масштаба, допустимого для разработки первичных требований к комплексу документации. Некоторые требования могут потребовать изменения (обычно увеличения) масштаба, и соответственно ресурсов на этапах предварительного и детального проектирования для обеспечения возможности реализации требуемой функциональной пригодности. Таким образом, требования к функциональной пригодности, к конструктивным характеристикам ПС, к форматам и структуре документации должны быть согласованы с масштабом проекта и доступными ресурсами для реализации, на ранних этапах его жизненного цикла. Для этого необходимо использовать адекватные методы и единицы измерения масштаба проектов ПС [16,17,19]. Формированию требований к комплексу программ должно сопутствовать создание требований, отражающих его документооборот, вследствие чего эти процессы во многом подобны. От масштаба ПС непосредственно зависят затраты ресурсов для их документирования и не всегда целесообразно создавать и использовать в реальных проектах весь комплекс шаблонов документов, отраженных в главе 3. Масштаб проекта и спецификация требований к ПС, непосредственно отражаются на составе, содержании и объеме документации, необходимой различным участникам проекта. Каждый из разработчиков в той или иной степени должен привлекаться к управлению требованиями, как к проекту, так и его документации. Разработчикам необходимо выработать профессиональные приемы для понимания и изложения в документах потребностей пользователей, управления масштабом проекта, построением системы и документации, удовлетворяющих достаточно полно эти потребности, которые включают: - команда разработчиков ПС, получает представление о сложности и размере создаваемого продукта и составе его документации; - менеджеры проекта, - базу для расчета содержания спецификаций, графиков, затрат и ресурсов; - группа тестирования, - планы тестирования, варианты испытаний и процедуры проверок; - специалисты по сопровождению и поддержке, получают представление о функциональности каждой составной части продукта; - клиенты отдела маркетинга и специалисты по продажам, будут иметь представление о конечном программном продукте; - составители документации, создающие шаблоны документов, руководства для пользователей и правки на основании спецификации требований к ПС получат проект пользовательского интерфейса; - специалисты, ответственные за обучение персонала, получат спецификации требований к ПС и документацию для пользователей, а также для разработки обучающих материалов; - персонал, занимающийся юридической стороной проекта, проверит, соответствуют ли требования к продукту существующим законам и постановлениям. Размер или масштаб комплексов программ в настоящее время приводится в публикациях в различных единицах, что может изменять их численные значения для одних и тех же программ в несколько раз [6, 13, 27]. В качестве таких единиц чаще всего используются численные значения: строк текста программы на языке программирования, предложений на ассемблере в тексте программы, байт или команд в объектном коде после трансляции. Каждая из этих единиц измерения может иметь некоторые преимущества при определенных целях исследования или проектирования. Влияние единиц измерения размера программ на оценку рационального объема документации может значительно изменяться, если учесть их принципиальные особенности и, прежде всего, выделить две группы единиц измерения масштаба проектов ПС [1, 8, 22]: - группу, характеризующую размер исходных текстов программ, которые разрабатываются и анализируются специалистами - человеком, отражающую, сложность, трудоемкость и длительность создания ПС, его компонентов и основных документов; - группу, отражающую размер программ и данных, размещаемых в реализующей (объектной) ЭВМ, и характеризующую объем памяти и производительность ЭВМ, необходимые для рабочего функционирования и исполнения комплекса программ в соответствие с его назначением. Эти две группы единиц отражают размер программ и документов, с разных позиций, и должны использоваться в зависимости от целей анализа и применения значений масштаба проекта. Хотя между ними есть корреляция, но в общем случае размеры программы, измеренные различными группами единиц, трудно сопоставлять из-за наличия между ними промежуточного звена - преобразователя (транслятора) с различными, не полностью определенными и трудно учитываемыми характеристиками. Это обусловлено особенностями трансляторов, которые преобразуют исходные тексты программ, разработанные человеком - программистом, в разделы памяти для исполнения реализующей ЭВМ, заполненные командами, константами или выделенные под данные, а также особенностями языков программирования, структуры и содержания машинных команд. Основная цель оценки масштаба ПС - подготовить возможность принять обоснованное решение о допустимости дальнейшего продвижения проекта в область системного анализа, разработки требований, предварительного проектирования и документирования. Если оказывается, что рассчитанные первично масштаб и требуемые ресурсы не могут быть обеспечены для продолжения проекта, то возможны кардинальные решения: либо изменение некоторых выделяемых ресурсов, либо прекращение проектирования данного ПС(рис. 1.3). Один из путей оценки размера ПС и состава комплекса документов, заключается в сравнении его функциональных задач и свойств с уже существующими аналогами. Конечно, данный метод не является точным, поскольку при написании компонентов прототипов и документов могли использоваться различные языки программирования, относящиеся к разным областям приложений
Рис. 1.3
Также могли применяться разнообразные алгоритмы, имеющие различные уровень сложности и функциональные свойства. Их выбор зависит от конкретных условий разработки проекта, а также от возможностей использования информации о ранее созданных прототипах с близкими функциональными характеристиками ПС. Когда впервые рассматривается масштаб нового проекта ПС, интуитивные и экспертные оценки его масштаба и состава требуемой документации заказчиками и разработчиками могут отличаться от конечного значения в несколько раз. Такая достоверность оценок обусловлена уровнем неопределенности на начальном этапе знаний о функциях, содержании и возможной сложности программного продукта. Для уменьшения этих неопределенностей и возможных методических ошибок необходимо определить основные понятия и единицы измерения масштаба комплексов программ. С самого начала работы над проектом ПС важно вести постоянный учет данных о его действительной трудоемкости, стоимости, содержании и комплексе документов и сравнивать эти данные с реальными оценками этих характеристик аналогичных проектов. Следует согласовывать цели оценивания масштаба документирования с потребностями в информации, зафиксированной в документах, способствующей принятию решений для планирования развития проекта, затрат труда и других ресурсов при последующем применении. Для продолжения разработки набора документов после оценки масштаба комплекса программ, необходимо выполнить цикл поэтапного определения и формирования совокупности спецификаций требований к компонентам и документации проекта ПС. Первым этапом является создание Концепции проекта ПС и комплекса первичных требований спецификаций к иерархическому набору функций, на которые могут быть разбиты предполагаемые фактические компоненты ПС - см. рис.1.3. В дальнейшем разбиение может структурироваться и детализироваться, формируя упрощенный или более точный уровень абстракции и взаимодействия компонентов. Цель документа - Концепция, состоит в сборе, анализе и определении высокоуровневых потребностей пользователей, функций и документов программного продукта. Основное внимание должно уделяться возможностям и функциям, в которых нуждаются будущие разработчики и пользователи, и причинам существования этих потребностей. После первичной оценки масштаба проекта ПС итерационно выполняется поэтапная разработка спецификаций требований проекта и документов ПС. Ограничения при прогнозировании требований к документам, определяются, прежде всего, имеющимися данными, которые могут быть использованы в качестве исходных аналогов или обобщенных характеристик. Будучи конечным хранилищем комплекса требований к продукту и документов, спецификация требований к ПС должна быть ясной и понятной, дабы у разработчиков и заказчиков не оставалось ни малейших возможностей для разночтения. Не обязательно составлять спецификацию для всего продукта до начала разработки, но необходимо зафиксировать требования для каждой составляющей перед ее созданием. При работе над любым проектом необходимо достичь согласованности решений по каждому набору требований и документов до начала их реализации разработчиками. Согласованность решений представляет собой процесс изучения и одобрения документов к ПС. В общем случае для оценки, прогнозирования и обоснования спецификаций требований нового комплекса документов необходимы исходные данные: - обобщенные характеристики использованных ресурсов для документирования и технико-экономические показатели завершенных разработок - прототипов ПС, а также оценки влияния на них функций, различных факторов объектов и среды разработки; - реализованные планы документирования и обобщенные перечни выполненных работ, реальные графики проведенных ранее оценок и разработок, различных ПС и документов; - цели и содержание частных работ в процессе создания предыдущих, сложных комплексов программ и различных документов я обеспечения необходимого качества ПС в целом; структура и содержание полного комплекта документов, явившегося результатом выполнения отдельных работ конкретного проекта. Составлять спецификацию требований к документации ПС следует таким образом, чтобы все заинтересованные в проекте лица смогли в ней разобраться [3, 4, 18]: - разделы, подразделы и отдельные требования должны быть Названы согласованно; - полезно использовать средства визуального выделения (такие, как полужирное начертание, подчеркивание, курсив и различные шрифты) последовательно, иерархически и в разумных пределах; - создавайте оглавление, а также алфавитный указатель, чтобы облегчить пользователям поиск необходимой информации; - нумеровать все рисунки и таблицы, ссылки на них, используя присвоенные номера. Чтобы легко отслеживать и модифицировать документы, каждое функциональное требование должно быть представлено уникально и неизменно. Это позволит ссылаться на определенные требования документов в запросе на изменения, в хронологии изменений, в перекрестных ссылках или матрице для отслеживания реализации требований. При этом также упрощается многократное использование документированных требований в нескольких проектах. Для устранения или снижения ошибок состава и рисков документации до допустимых пределов может быть необходимо изменение требований к функциональной пригодности и/или к конструктивным характеристикам и доступным ресурсам проекта ПС. Поэтому на этапах проектирования последовательно должны определяться [2, 14, 23, 28] (см. рис.1.3): при проектировании концепции и первичной оценке масштаба проекта - предварительные требования к назначению, функциональной пригодности, к составу и номенклатуре необходимых конструктивных характеристик качества и к первичному перечню набору документов ПС; при предварительном проектировании - уточненная оценка масштаба проекта, требования к функциональным и конструктивным характеристикам качества, к ориентировочной структуре и содержанию набора шаблонов документов в жизненном цикле ПС с учетом общих ограничений ресурсов; при детальном проектировании - подробные спецификации требований к функциональным и конструктивным характеристикам качества с детальным учетом и распределением реальных ограниченных ресурсов, а также полный состав и содержание шаблонов документов в жизненном цикле ПС Разработку и утверждение спецификаций требований к функциональным характеристикам, к качеству, составу и номенклатуре документов ПС, целесообразно проводить итерационно на этапах предварительного и детального проектирования. Полная и однократная формализация требований к характеристикам и комплекту документов в начале жизненного цикла сложного ПС обычно невозможна, прежде всего, из-за разных представлений заказчика и разработчиков о деталях его назначения, функций и возможностей реализации при доступных ресурсах. Чем крупнее и сложней проект ПС и соответственно выше его стоимость, тем тщательнее следует разрабатывать требования к его характеристикам, к составу и содержанию документов, а также распределять ресурсы на их реализацию. Поэтому при средней и относительно невысокой сложности ПС во многих случаях можно удовлетвориться подготовкой требований к комплексу программ с подробностью анализа, соответствующего предварительному проектированию. Для крупномасштабных и особо сложных проектов необходим более детальный анализ факторов при разработке набора документов (см. п. 1.5 и главу 3) и требований их оптимизации по критерию качество/затраты в детальном проекте. При первоначальном определении требований к функциональной пригодности и к конструктивным характеристикам, заданные заказчиком ограничения ресурсов не всегда могут учитывать ряд особенностей проекта, что может обусловить недопустимое снижение (или завышение) требований к некоторым характеристикам и Документам ПС. Кроме того, возможно, что некоторые характеристики противоречивы или принципиально нереализуемы в данном проекте. В результате не сбалансированные требования и доступные ресурсы проявятся в виде потерь в качестве или в потребности Дополнительных ресурсов. В зависимости от сложности проекта окончательным результатом работ при предварительном или детальном документировании проекта должны быть детализированные и утвержденные документу спецификаций к номенклатуре, свойствам, значениям качества и Документации проекта ПС, которые достаточны для его полноценного рабочего проектирования и последующей, эффективной эксплуатации. Эти требования к документам закрепляются в контракте и техническом задании, по которым разработчик впоследствии должен отчитываться перед заказчиком при завершении проекта. Однако на последующих этапах жизненного цикла и при конфигурационном управлении, документы могут изменяться по согласованию между заказчиком и разработчиком, которые чаще всего приурочиваются к подготовке новой версии ПС. Для этого необходим мониторинг масштаба проекта, комплекта документов, специ-фикаций требований и реализаций характеристик в течение всего ЖЦПС. Для разработчиков особенно важно формализовать требования к качеству и согласовать их с заказчиком при утверждении контракта и технического задания на проект ПС. Требования к функциональным характеристикам, качеству, составу и содержанию документов, утвержденные после предварительного проектирования, могут быть закреплены в техническом задании как обязательные для детального и рабочего проектирования. Эти данные могут использоваться при последующем оценивании качества документации при их сопоставлении с требованиями в процессе квалификационных испытаний или сертификации ПС. Однако для крупномасштабных и дорогих проектов может потребоваться уточнение требований к качеству документации при детальном проектировании с позиции улучшения соотношения значений качества и затрат ресурсов, которые необходимы или допустимы для их реализации в ЖЦ ПС [16, 24,30]. Для заказчика и пользователей может иметь значение не только определение функциональной пригодности, но и оценка потенциального спроса на рынке конкретного программного продукта, а также его конкурентоспособности с другими аналогичными по функциям ПС с учетом его качества и стоимости. Это обстоятельство может определять необходимость уточнения требований к отдельным характеристикам и документам не только для их реализации разработчиками в ЖЦ ПС, но также для оценивания интегрального качества готового программного продукта поставляемого на рынок. Обычно заказчики и разработчики первоначально устанавливают требования к каждой характеристике и к номенклатуре документов ПС без учета относительных затрат на их достижение, а также без детального анализа их совместного влияния на полную функциональную пригодность у потребителей. Это может приводить к значительным перекосам и к несбалансированным значениям требований к отдельным, взаимосвязанным характеристикам и документом, на которые не рационально используются ограниченные ресурсы ЖЦ ПС, или к не адекватно низким их значениям. В проектах крупномасштабных ПС это может угрожать значительным повышением стоимости и/или снижением конкурентоспособности создаваемого программного продукта из-за недостаточного уровня отдельных показателей качества и документов. Атрибуты качества ПС и важность (полезность) документов имеют различные меры, вследствие чего они в большинстве своем непосредственно не сопоставимы между собой. Они предварительно выбираются и согласовываются с заказчиком при последовательном, почти независимом анализе каждого документа, для использования в контракте и техническом задании. Для обобщенного оценивания качества ПС необходим учет относительного влияния каждой конструктивной характеристики и документа, на функциональную пригодность. При этом не всегда учитываются ресурсы для их реализации в конкретном ПС. Это часто приводит к не рациональным требованиям и документам, которые значительно отличаются: либо по степени влияния на функциональную пригодность, либо по величине ресурсов, необходимых для их реализации как полноценных документов. Для эффективного управления документацией сложного ПС при детальном проектировании целесообразно учитывать и обобщать степень полезности разнородных характеристик и документов в некоторый интегральный показатель, отражающий их совокупное влияние на его функциональную пригодность. Таким образом, при разработке требований к характеристикам документов проекта выявилась проблема анализа системной эффективности документации и обобщения их характеристик, а также оценивания совместного влияния различных документов на функциональную пригодность ПС с учетом затрат на их реализацию. Для управления и сопоставительного оценивания выбранных Характеристик качества документов целесообразно каждому из них присваивать коэффициент или приоритет влияния на функциональную пригодность. Точность определения коэффициентов вряд ли может превышать 10%, поэтому количество градаций шкалы оценок целесообразно не больше десяти. Аналогично, по такой же трудно. Такие оценки могут проводиться на основе специальных маркетинговых исследований и опыта эксплуатации аналогичных комплексов программ или достаточно близких их прототипов. Это подтверждает целесообразность выделения для автономного анализа интегральных характеристик программного продукта и документов и их влияния на функциональную пригодность. Работа по подготовке и определению документирования может быть затруднена, если новый проект не имеет аналогов, то есть отсутствуют предварительные наработки в данном предприятии. Для уникального, не имеющего аналогов проекта должны быть предприняты специальные мероприятия, обеспечивающие документирование и соответствующий надзор за реализацией документов. Данные мероприятия должны сопровождаться соответствующими анализами и оценками, и экспертными заключениями. Должны быть предусмотрены специальные мероприятия для управления изменениями в области управления документацией в жизненном цикле программного проекта. Все изменения, вносимые в документы и требования, должны быть тщательно оценены по их влиянию на стоимость, графики работ, риски и эффективность характеристик проекта.
Планування документування проектів Общее руководство процессом документирования комплексов программ можно разделить на два уровня: - адаптация состава и содержания документов к данной деловой, проблемно-ориентированной области, например, авиационной, медицинской, военной, финансовой или административной; - адаптация номенклатуры, структуры и содержания документов для каждого специфического проекта, контракта или предприятия. В соответствии со стандартами план документирования в виде совокупности руководящих, промежуточных и отчетных документов должен разрабатываться системными аналитиками и утверждаться менеджером проекта вместе со спецификацией требований к ПС (см. п. 1.2). В спецификации формализуются требования к результатам документирования, а в плане - методы и средства их дос-т. Тем самым характеристики ПС не только декларируются в виде требований, но и сопровождаются совокупностью рекомендуемы мероприятий и документов по их обеспечению и реализации. Первичные требования к документированию при проектировании детализируются по компонентам ПС и по этапам их создания. При этом важно обеспечить баланс жесткости требований к качеству различных компонентов и документов с тем, чтобы в ПС не было доминирующих компонентов, заметно снижающих значения важнейших показателей качества, или напрасных затрат ресурсов на высокое качество документов, слабо влияющих на функциональную пригодность ПС и общее качество документации проекта в целом. При первичной оценке ресурсов, необходимых для документи-рования сложных проектов ПС наибольшее значение имеют три ключевых фактора: - размер - масштаб, подлежащих разработке полностью новых программных компонентов и документов; - размер и относительная доля готовых программных компонентов и документов, которые могут быть заимствованы из предшествовавших проектов и повторно использованы в новом проекте ПС; - относительные затраты ресурсов на создание проекта с оцененным масштабом: труда специалистов, времени, бюджета на единицу размера (на строку текста программ) или полные затраты на разработку всего ПС и комплекса документов. - Эти факторы могут быть оценены квалифицированными экспертами на основе имеющегося у них опыта реализации предшествовавших подобных проектов, а также использования опубликованных данных (см. п. 1.1). Достоверность прогнозов требующихся ресурсов для документирования зависит, прежде всего, от точности оценки исходных данных. Они позволяют использовать опыт прошлых разработок и их отличия от новых методов, предусмотренных в конкретных проектах, а также индивидуальные возможности коллектива разработчиков или другие уникальные особенности проекта оценки зависят от компетенции и объективности экспертов, оптимистичности, пессимистичности и знания существен особенностей проекта. При наличии перечисленных исходных и положительной оценке целесообразности для экспертного ресурсов документирования проекта может использоваться методика, состоящая из следующих шагов оценка размера - масштаба, числа строк предполагаемого текста разрабатываемых программ, с учетом размера повторно используемых компонентов и характеристик возможного языка программирования; - расчет возможной полной трудоемкости и длительности раз работки проекта ПС, а также среднего числа специалистов, необходимых для его реализации и документирования; - обобщение основных технико-экономических показателей и полной стоимости разработки проекта и документирования ПС, анализ результатов, и обоснование рентабельности продолжения проектирования комплекса программ. Оценивая масштаб, функции и требования к документации, заказчик и разработчики должны хотя бы приближенно представлять тот объем затрат и физический размер комплекса документации, который придется создать в процессе всего жизненного цикла ПС, а также для обеспечения его эффективного применения. Известно, что на документирование крупномасштабных ПС требуется до 20 - 30% общей трудоемкости создания таких проектов, а для относительно малых проектов около 10% трудоемкости. Представляет интерес оценка ориентировочного физического объема документации (например, в стандартных страницах А4 или эквивалентных объемов файлов) для проектов комплексов программ. В качестве примера выделим два масштаба проектов: малый -50 тысяч строк и крупный один миллион строк, и выделим оценки на технологическую и на эксплуатационную документацию. В эксплуатационной документации обычно не оформляются и не приводятся спецификации компонентов, тексты программ с комментариями, тесты и результаты тестирования, что резко сокращает номенклатуру документов до трех - семи видов (см. п. 3.7). Каждое описание, руководство или инструкция может содержать до 100 страниц текста, что в совокупности дает до тысячи страниц эксплуатационных документов. Для крупного программного продукта несколько возрастает номенклатура документов, но главное, по крайней мере, пропорционально увеличению сложности и масштаба комплекса программ до 10 6 строк, объем эксплуатационной документации может увеличиться до 10 тысяч страниц. Номенклатура технологических документов в жизненном цикле крупномасштабного ПС может доходить до 50 видов, среди которых наибольшее влияние на объем документации оказывают: спецификации программ и данных, тексты программ с комментариями, тестовые сценарии и результаты тестирования компонентов и модулей. Для отражения совокупности этих документов, в среднем на каждую строку текста программы может требоваться от 10% до полной страницы документации. Остальные документы в основном являются интегральными для проекта и вряд ли займут более 10% общего объема от перечисленных категорий документов. Таким образом, технологическая документация для жизненного цикла ПС размером Ю 6 строк может составить около ста тысяч страниц или ста томов по тысяче страниц. Вряд ли целесообразно изготавливать такой объем твердых копий документов на бумаге. Большая часть этих документов может оставаться в файлах (сотни мегабайт), однако каждый документ должен быть оформлен в соответствии со стандартами и шаблонами, и скреплен подписями разработчиков и, где нужно, заказчика. Изменение этих документов должно санкционироваться, также как твердых копий. Для относительно малого ПС (50 тысяч строк) с минимальной технологической документацией может потребоваться около 5 тысяч страниц. Приведенные оценки следует рассматривать только как ориентиры, которые в реальных проектах могут изменяться на порядок в ту или иную сторону, в зависимости от требований заказчика и характеристик проекта. Оценки объема предстоящей разработки технологической и эксплуатационной документации целесообразно проводить на этапе детального проектирования с учетом реальных характеристик ПС, что позволит избежать неприятных сюрпризов вызванных превышением затрат на реализацию документов проекта. Менеджер проекта для оценок документации должен подготовить план выполнения документирования в жизненном цикле ПС. тот план должен содержать описания соответствующих работ и задач и обозначения создаваемых программных продуктов и документов. Он должен охватывать (но не ограничиваться) следующие задачи: - установление графиков и сроков своевременного решения документирования; - оценку необходимых трудозатрат на создание каждого документа и всего комплекса; определение времени, необходимого для выполнения конкретных задач документирования; - распределение задач документирования по исполнителям; - определение обязанностей исполнителей по созданию содержания документов; - выделение критических ситуаций, связанных с задачами или самим процессом документирования; - установление критериев управления и обеспечение качества документов; - обеспечение внешних условий и определение инфраструктуры проекта системы для выполнения процесса документирования. В проекте ПС должен быть определен базовый график выполнения работ, а графики документирования отдельных документов должны быть связаны и согласованы с этим базовым графиком. Менеджер каждого программного проекта должен стремиться по возможности использовать существующую организационную инфраструктуру документирования на предприятии. Должен быть определен механизм для разрешения или преодоления конфликтных ситуаций между менеджером всего проекта ПС и администратором процесса документирования на соответствующем уровне их полномочий по организационному управлению. Это положение является общим для всех контрольных этапов, связанных с выполнением договорных обязательств по вспомогательным процессам (например, оп-ределением конкретной базовой версии), поэтому необходимы син-хронизация соответствующих планов и своевременное уведомление менеджера ПС о всех затруднениях, возникающих при выполнении соответствующих задач процессов документирования. Номенклатура, структура и содержание документов определяется конкретной моделью жизненного цикла и масштабом рассматриваемого ПС (см. рис. 1.2 и Приложение 1). В интересах сокращения стоимости и улучшения качества, стандарты и регламентируемый ЖЦ ПС рекомендуется адаптировать к характеристикам конкретного проекта. Соответственно сформированному жизненному циклу следует адаптировать состав документов конкретного проекта ПС (см. п. 1.5). Для адаптации состава и содержания документации, должны быть определены характеристики окружения проекта, которые могут воздействовать на адаптацию документирования: процессы жизненного цикла создаваемой системы; требования к системе и программному средству; организационные процедуры и стратегии документирования; размер, критичность и функции основных компонентов системы; количество задействованного в проекте персонала и сторон. Планирование и управление разработкой ПС и документов Проходят несколько этапов и реализуются во времени по мере повышения достоверности исходных данных об объекте и среде разработки. На этих этапах происходит постепенный переход от предварительных прогнозов к планированию и последующему непосредственному управлению текущими работами документирования. Этому способствуют расширение коллектива специалистов и относитель-ное снижение творческого характера выполняемых работ. Наиболее творческий этап документирования системного анализа, в котором участвует минимум высококвалифицированных специалистов, последовательно переходит в этапы предварительного, детального и рабочего проектирования, на которые привлекается для документирования все большее число специалистов в среднем меньшей квалификации для выполнения более частных и менее творческих работ и документов. План документирования может быть частью общего плана жизненного цикла ПС или отдельным документом и должен быть доведен до всех участников проекта, в той части, которая их касается. План и поддерживающее его Руководство по документированию конкретного проекта ПС должны отражать: - общую структуру комплекта документов; - номенклатуру и содержание (или ссылки на шаблоны) каждого документа; - требования к качеству, оформлению и обозначению документов; - регламент комплектования и хранения документов; - правила обращения, изменения и сопровождения документов; - графики подготовки, проверки, редактирования, согласования, утверждения и распространения документов. В плане управления документированием каждого этапа жизненного цикла ПС необходимо фиксировать и документально - оформлять (см. рис. 1.3): исходные данные (шаблоны), требующиеся для успешного выполнения данного этапа документирования проекта или компонента ПС; - контролируемые и документируемые данные о состоянии объекта и процесса разработки, регистрируемые после завершения этапа; - содержание процедур контроля состояния проекта и документов в процессе выполнения работ этапа; - критерии оценки результатов выполненных работ и качества отчетных документов при завершении этапа; - состав и содержание отчетных документов (шаблонов), представляемых для оценки состояния проекта, результатов завершенного этапа и работ и для использования на следующем этапе или при завершении проекта ПС. Менеджер программного проекта должен отвечать за проведение оценок программных продуктов, документов и планов: на соответствие принципам, методологии и технологии управления проектом и документированием; в части удовлетворения их установленным требованиям договора с заказчиком. Необходимыми компонентами успешной реализации программных проектов являются периодические анализы и оценки хода выполнения и завершения этапов и заданий на документирование. Проверки и оценки документов должны быть проведены для выделения областей технического и финансового риска [14, 23, 28]: - план тестирования документов должен быть определен в начале жизненного цикла программного проекта; - необходимо учитывать, что следствием нарушения графика работ, предшествующих тестированию документов, без соответствующей корректировки даты поставки компонента может быть не достаточно полное тестирование программного продукта; - должны быть установлены строгие правила регистрации, хранения, модернизации, резервирования и сопровождения документов, контрольных (тестовых) данных и среды тестирования документов; - должна быть разработана стратегия возврата к исходному состоянию документов при тестировании изменений программного продукта; необходим единый (интегрированный) план сборки документов системы и компонентов ПС в соответствии со стратегией выпуска очередных версий системы и комплекса документов; - должно быть представлено явное подтверждение функциональных возможностей ПС и системы, показывающее соответствие возможностей комплекса документов текущим и запланированным потребностям пользователя. Прогнозы технологических процессов документирования являются основой для выбора, предварительного планирования и последующего системного анализа всего процесса создания ПС и комплекса документов. Достоверность планов и прогнозов определяет точность сведений о размере документирования объекта разработки, характеристиках технологической среды и прототипов, принятых за основу при планировании. Таким образом, определяются приближенные значения трудоемкости и длительности всей разработки ПС, а также число необходимых специалистов, что позволяет оценить предварительный укрупненный план создания ПС в заданных условиях. Вследствие творческого характера большинства работ на этом этапе невозможно составить жесткий план их выполнения. При реализации этих работ менеджер проекта должен отвечать за надзор, обеспечивающий немедленное обнаружение и анализ любых отклонений от запланированного выполнения конкретного документирования, и внесение соответствующих корректировок в ход данного процесса. Измерения состояния и размера документации могут быть использованы для проверки соответствия между ожидавшимися Функциями программного продукта и его функциями при эксплуатации. Планирование качества документов в ряде стандартов принято отделять от планов непосредственного управления процессом создания комплекса программ. Для реализации планов качественного Документирования должны быть созданы регламентирующие документы охватывающие: - процессы создания документов, отражающих ка
|
