Формування вимог до документації

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

Формированию требований к комплексу программ должно сопутствовать создание требований, отражающих его документооборот, вследствие чего эти процессы во многом подобны. От масштаба ПС непосредственно зависят затраты ресурсов для их документирования и не всегда целесообразно создавать и использовать в реальных проектах весь комплекс шаблонов документов, отраженных в главе 3. Масштаб проекта и спецификация требований к ПС, непосредственно отражаются на составе, содержании и объеме документации, необходимой различным участникам проекта. Каждый из разработчиков в той или иной степени должен привлекаться к управлению требованиями, как к проекту, так и его документации. Разработчикам необходимо выработать профессиональные приемы для понимания и изложения в документах потребностей пользователей, управления масштабом проекта, построением системы и документации, удовлетворяющих достаточно полно эти потребности, которые включают:

- команда разработчиков ПС, получает представление о сложности и размере создаваемого продукта и составе его документации;

- менеджеры проекта, - базу для расчета содержания спецификаций, графиков, затрат и ресурсов;

- группа тестирования, - планы тестирования, варианты испытаний и процедуры проверок;

- специалисты по сопровождению и поддержке, получают представление о функциональности каждой составной части продукта;

- клиенты отдела маркетинга и специалисты по продажам, будут иметь представление о конечном программном продукте;

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

- специалисты, ответственные за обучение персонала, получат спецификации требований к ПС и документацию для пользователей, а также для разработки обучающих материалов;

- персонал, занимающийся юридической стороной проекта, проверит, соответствуют ли требования к продукту существующим законам и постановлениям.

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

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

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

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

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

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

Для заказчика и пользователей может иметь значение не только определение функциональной пригодности, но и оценка потенциального спроса на рынке конкретного программного продукта, а также его конкурентоспособности с другими аналогичными по функциям ПС с учетом его качества и стоимости. Это обстоятельство может определять необходимость уточнения требований к отдельным характеристикам и документам не только для их реализации разработчиками в ЖЦ ПС, но также для оценивания интегрального качества готового программного продукта поставляемого на рынок.

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

Для управления и сопоставительного оценивания выбранных Характеристик качества документов целесообразно каждому из них присваивать коэффициент или приоритет влияния на функциональную пригодность. Точность определения коэффициентов вряд ли может превышать 10%, поэтому количество градаций шкалы оценок целесообразно не больше десяти. Аналогично, по такой же трудно. Такие оценки могут проводиться на основе специальных маркетинговых исследований и опыта эксплуатации аналогичных комплексов программ или достаточно близких их прототипов. Это подтверждает целесообразность выделения для автономного анализа интегральных характеристик программного продукта и документов и их влияния на функциональную пригодность.

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

Дата добавления: 2015-05-08