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

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

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

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

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

Проблемы прогнозирования физического объема комплекса документов для конкретных проектов программного средства. Базой для таких оценок можно использовать соответствующую модель жизненного цикла ПС. Последующее изложение базируется на применении сокращенной каскадной модели жизнен­ного цикла сложных программных средств (см. стандарт ГОСТ Р 16326), представленной на рис. 1.2, которая используется в п. 1.5 и главе 3 при структурировании групп шаблонов документов, поддерживающих выделенные этапы ЖЦ ПС. Ниже приводятся рекомендации по структуре и содержанию более шестидесяти шаблонов типовых документов, сконструированных так, что возможны их выбор и адаптация в соответствии с масштабом и характеристиками проектов ПС. Адаптация является процессом в основном исключения процедур и компонентов документов, не применимых в конкретном проекте. Добавление уникальных или специфических документов должно быть оговорено в контракте или конкретной методике. Архитектура и содержание шаблонов документов на ПС, далее не конк­ретизируется в деталях, как их реализовать, оформить и оценить суммарный объем комплекса документов для определенного проекта, вследствие большого числа неопределенных параметров. Эти задачи должны решаться индивидуально с использованием Руководящих документов по подготовке и оформлению конкретных эксплуатационных и технологических документов для пользователей и разработчиков определенных проектов ПС. Стороны ответ­ственны за выбор и применение методов и инструментальных средств автоматизации разработки и оценки суммарных размеров совокупности документов, а также за выбор процедур и документов, подходящих для оценки конкретного проекта ПС или системы.

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

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

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

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

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

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

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

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

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

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

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

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