Формирование требований к документации сложных программных средств

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

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

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

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

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

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

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

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

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

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

Размер или масштаб комплексов программ в настоящее время приводится в публикациях в различных единицах, что может изменять их численные значения для одних и тех же программ в несколько раз (см. лекцию 5). Влияние единиц измерения размера программ на оценку рационального объема документации можно значительно изменяться, если учесть их принципиальные особенности и, прежде всего, выделить две группы единиц измерения масштаба проектов ПС:

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

- группу, отражающую размер программ и данных, размещаемых в реализующей (объектной) ЭВМ, и характеризующую объем памяти и производительность ЭВМ, необходимые для рабочего функционирования и исполнения комплекса программ в соответствие с его назначением.

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

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

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

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

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

- структура и содержание полного комплекта документов, являвшегося результатом выполнения отдельных работ конкретного проекта.

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

- разделы, подразделы и отдельные требования должны быть названы согласованно;

- полезно использовать средства визуального выделения (такие, как полужирное начертание, подчеркивание, курсив и различные шрифты) последовательно, иерархически и в разумных пределах;

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

- нумеровать все рисунки и таблицы, ссылки на них, используя присвоенные номера.

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

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

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

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

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

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

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

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

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

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

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

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

17.3. Планирование документирования проектов сложных программных средств

Общее руководство процессом документирования комплексов программ можно разделить на два уровня:

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

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

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

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

Может представлять интерес оценка ориентировочного физического объема документации (например, в стандартных страницах А4 или эквивалентных объемов файлов) для проектов комплексов программ. В качестве гипотетического примера выделим два масштаба проектов: малый – 50 тысяч строк и крупный – один миллион строк, и выделим оценки на технологическую и на эксплуатационную документацию. В эксплуатационной документации обычно не оформляются и не приводятся спецификации компонентов, тексты программ с комментариями, тесты и результаты тестирования, что резко сокращает номенклатуру документов до трех – семи видов (см. таблицу 17.7). Каждое описание, руководство или инструкция может содержать до 100 страниц текста, что в совокупности дает до тысячи страниц эксплуатационных документов. Для крупного программного продукта несколько возрастает номенклатура документов, но главное, пропорционально увеличению сложности и масштаба комплекса программ до 10 ⁶ строк, объем эксплуатационной документации может увеличиться до 10 тысяч страниц.

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

Вряд ли целесообразно изготавливать такой объем твердых копий документов на бумаге. Большая часть этих документов может оставаться в файлах (сотни мегабайт), однако каждый документ должен быть оформлен в соответствии со стандартами и шаблонами, и скреплен подписями разработчиков и, где нужно, заказчика. Изменение этих документов должно санкционироваться, также как твердых копий. Для относительно малого проекта ПС (50 тысяч строк) с минимальной технологической документацией может потребоваться около 5 тысяч страниц или эквивалентных файлов.

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

Менеджер проекта для оценок объема и содержания документации должен подготовить план выполнения документирования в жизненном цикле ПС (рис. 17.2). Этот план должен содержать описания соответствующих работ и задач и обозначения создаваемых программных продуктов и документов. Он должен охватывать следующие задачи:

- установление графиков и сроков своевременного решения задач документирования;

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

- определение времени, необходимого для выполнения конкретных задач документирования;

- распределение задач документирования по исполнителям;

- определение обязанностей исполнителей по созданию содержания документов;

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

- установление критериев управления и обеспечение качества документов;
- обеспечение внешних условий и определение инфраструктуры проекта системы для выполнения процесса документирования.

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

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

В плане управления документированием каждого этапа жизнен­ного цикла ПС целесообразно фиксировать и документально оформлять:

- исходные данные (шаблоны), требующиеся для успешного выполнения дан­ного этапа документирования проекта или компонента ПС;

- контролируемые и документируемые данные о состоянии объекта и процесса разработки, регистрируемые после завершения этапа;

- содержание процедур контроля состояния проекта и документов в процессе выполнения работ этапа;

- критерии оценки результатов выполненных работ и качества отчетных документов при завершении этапа;

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

Менеджер программного проекта должен отвечать за проведение оценок программных продуктов, документов и планов: на соответствие принципам, методологии и технологии управления проектом и документированием; в части удовлетворения их установленным требованиям договора с заказчиком. Необходимыми компонентами успешной реализации программных проектов являются периодические анализы и оценки хода выполнения и завершения этапов и заданий на документирование.

Планирование качества доку­ментов в ряде стандартов принято отделять от планов непосредственного управления процессом создания комплекса программ. Для реализации планов качественного документирования должны быть созданы регламентирующие документы охватывающие:

- процессы создания документов, отражающих качество программного продукта;

- обязанности и ответственность специалистов за качество конкретных документов;

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

- требования к качеству конкретных документов и способы его контроля.

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

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

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

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

Первоначально должен быть разработан проект архитектуры системы документооборота и руководство по её применению, настроена выбранная СУБД на управление взаимодействующими подсистемами документооборота, с соответствующими комплектами выбранных шаблонов документов, с учетом класса и масштаба предполагаемого ЖЦ ПС (см. лекцию 16 п. 16.3). Шаблоны подсистем документооборота должны поэтапно заполняться реальными данными проекта от заказчика и разработчиков соответствующих квалификаций, и контролироваться менеджерами проекта. При этом следует управлять динамикой процессов реализации процедур документооборота, регистрировать реальное использование ресурсов специалистов, текущее время выполнения процедур процессов ЖЦ ПС и оформления документов в подсистемах. В реальных проектах ПС возможны отклонения от такой линейной схемы двух типов:

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

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

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

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

На базе стандартов, представленных в Приложении 1, с учетом ряда публикаций и норма­тивных документов, созданы и представлены ниже семь таблиц, отражающих состав комплекта технологических и эксплуатационных документов жизненного цикла ба­зовой версии сложного программного средства реального времени, создаваемого "с нуля". По ряду работ (например, програм­мирование компонентов) в ЖЦ ПС рекомендуется использовать специфические документы, детально регламентирующие содержание и применение определенных технологических процедур в соответствии с инструк­циями использования инструментальных средств. Детальную структуру каждого документа целесообразно уточнять менеджерам предприятия или проекта, в соответствии с их традициями, используемой технологией и особен­ностями проектируемого программного продукта. Формализованная структура и типовое содержание каждого документа должны позволять контро­лировать результаты и качество выполненных работ.

Представленный в таблицах 17.1 – 17.7 перечень документов в реальных проектах может варьироваться в зависимости от класса, масштаба и характе­ристик ЖЦ программного средства. Наиболее сложному случаю разработки крупномасштабных критических ПС реального времени высо­кого качества соответствует номенклатура и детали­зация всего комплекта представленных документов. Для каждого этапа жизненного цикла выделены три уровня сложности проектов ПС: особо сложные (свыше 200 тысяч строк – крупные), средние по масштабу (свыше 50 тысяч строк – средние) и небольшие проекты программных средств (малые). Рекомендуемые для таких проектов документы в таблицах отмечены знаком +. Некоторые документы целесообразно применять факультативно, или с сокращением и упрощением содержания, что отмечено знаками + –. Выделенные три перечня доку­ментов, целесообразно использовать как типовые, базовые, при адап­тации и формировании состава и содержания документов в конкрет­ных проектах, с учетом их особенностей, масштаба и характеристик.

Дата добавления: 2014-01-13