Проблеми організації документування

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

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

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

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

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

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

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

Рис. 1.1

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

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

- интервьюирование и анкетирование заказчиков и потенциальных пользователей;

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

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

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

- создание и апробацию прототипов и версий документов.

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

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

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