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

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

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

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

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

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

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

понять ограничения, которые могут сопутствовать или препятствовать решению проблем документирования.

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

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

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

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

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

В процессе установления стратегии, стандартов и руководств по документированию конкретного проекта ПС необходимо осуществить:

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

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

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

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

установление процедур реализации шаблонов документов;

распределение ресурсов для документирования: персонала; технических средств; финансов, а также на планирование документирования.

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

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

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

описание регламента работ документирующих подразделений;

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

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

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

стандартами и нормативными документами, определяющими все аспекты документирования программ и данных;

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

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

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

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

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

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