Фактически, этот стандарт аналогичен Техническому заданию, потому что определяет форму описания и состав требований главных разделов ТЗ (1-3) в соответствии с отечественным стандартом ГОСТ 34.602-89 [2.1.2].
Приведем необходимые части СТПО в соответствии с этим стандартом:
- Оглавление.
- Раздел 1. Введение:
- Цель (для чего и для кого).
- Границы применения (наименование, где будет применяться, что будет и не будет делать, каковы преимущества).
- Термины, аббревиатуры, сокращения (может выполняться в виде отдельного Глоссария).
- Ссылки.
- Краткий обзор (описание структуры и краткое содержание остальной части).
- Раздел 2. Общее описание:
- Описание изделия (взаимосвязь с другими системами):
- Интерфейсы системы.
- Интерфейсы пользователя.
- Интерфейсы аппаратных средств ЭВМ.
- Интерфейсы программного обеспечения.
- Интерфейсы коммуникаций (средств связи типа протоколов локальной сети и т.д.).
- Ограничения памяти.
- Функционирование (иногда является частью раздела Интерфейса пользователя) - определение нормальных и специальных действий типа:
- Различные способы действий в организации пользователя; например операции, инициируемые пользователем.
- Периоды диалоговых действий и периоды оставленных без отклика действий.
- Функции поддержки обработки данных.
- Действия резервного копирования и восстановления.
- Требования настройки рабочих мест.
- Функции изделия (сгруппированные и с диаграммами).
- Характеристики пользователя.
- Ограничения - факторы, ограничивающие выбор разработчика, например:
- Регулирующая политика.
- Ограничения аппаратных средств.
- Интерфейсы с другими приложениями.
- Параллельную работу.
- Функции протоколирования.
- Функции управления.
- Требования к языкам высокого уровня.
- Протоколы интерфейсов синхронизации сигналов.
- Требования надежности.
- Критичность приложения.
- Соображения безопасности и секретности.
- Предположения и зависимости – эти факторы не являются ограничениями на программное обеспечение проекта, но любое их изменение может затронуть требования в СТПО (например, предположение, что на аппаратных средствах ЭВМ, будет доступна определенная операционная система, и, если, фактически, ОС не доступна, СТПО должны были бы измениться).
- Поднаборы (распределение) требований - требования, которые могут быть отсрочены до будущих версий системы.
- Перспективы изделия.
- Раздел 3. Детальные требования:
- Внешние интерфейсы - детальное описание всех входов и выходов системы программного обеспечения (дополнением к описанию интерфейса в Разделе 2), включает:
- Наименование пункта.
- Описание цели.
- Источник входных или назначение выходных данных.
- Диапазон допустимых значений, точность и/или допустимые отклонения.
- Единицы измерения.
- Временные характеристики.
- Отношения к другим входам / выходам.
- Форматы / организация экрана.
- Форматы / организация окна.
- Форматы данных.
- Форматы команд.
- Конечные сообщения.
- Функции.
- Требования исполнения.
- Требования логики базы данных.
- Ограничения проекта.
- Характеристики программного обеспечения системы.
- Надежность.
- Эксплуатационная готовность.
- Безопасность.
- Ремонтопригодность.
- Переносимость.
- Структурирование детальных требований.
- Режим системы.
- Классы пользователей.
- Объекты.
- Особенности.
- Воздействие.
- Реакция.
- Функциональные иерархии.
- Дополнительные комментарии.
Это - часто самая большая и наиболее важная часть СТПО, поэтому необходимо применять следующие принципы:
- Детальные требования должны быть заявлены в соответствии с правилами п. 4.3. («Характеристики хороших СТПО») данного стандарта.
- Детальные требования должны иметь перекрестные ссылки к более ранним документам, к которым имеют отношение.
- Все требования должны быть уникально идентифицированы.
- Для повышения удобочитаемости необходимо особое внимание уделить структурированию требований.
Глоссарий используется лишь как приложение к Спецификации требований к ПО (СТПО). Определения терминов – четкие и краткие, без «энциклопедических» обзоров. Назначение Глоссария – однозначность трактовок терминов, используемых в СТПО.
Технология обеспечения качества в ЖЦ ПС представлена в стандарте ISO 9000-3:1991. Руководящие указания предназначены для унификации описания методов разработки и поставки ПС, а также способов контроля их качества, отвечающих требованиям заказчика. Этой унификации предлагается добиваться, предотвращая отклонения от стандарта на всех этапах ЖЦ - от начала разработки до технического обслуживания и ремонта. Предполагается, что в контракте будут особо оговорены важнейшие компоненты технологии проектирования и требования к техническим характеристикам ПС, иначе это делается в процессе разработки. Поставщик должен документально оформить цели, технологию и свои обязательства по обеспечению качества ПС. Необходимо определить ответственность, полномочия и взаимодействие всего руководящего, исполняющего работы и контролирующего персонала, который влияет на качество, надежность и безопасность применения создаваемого комплекса программ. Обеспечение и проверка качества проводится персоналом поставщика, независимым от специалистов, непосредственно ответственных за выполнение работ и создание изделий. Покупатель-заказчик назначает своего представителя, ответственного за сотрудничество с поставщиком в процессе создания ПС по данному контракту.
В стандарте определена структура системы обеспечения качества и ее функции в жизненном цикле ПС. Эта деятельность предусматривает:
- анализ содержания контракта, поддержанного методиками, обеспечивающими качество ПС;
- специфицирование требований заказчика, включающих все функциональные и технические характеристики, необходимые для удовлетворения запросов заказчика;
- планирование процесса создания ПС, включающее формализацию этапов, графика, ресурсов, методов и средств разработки, а также контроля и способов проверки результатов по всем этапам;
- планирование обеспечения качества компонентов, а также ПС в целом, которое должно актуализироваться и конкретизироваться по мере проведения разработки;
- проектирование и реализацию проекта, для чего определяются методология и средства проведения соответствующих работ, а также анализируются результаты обеспечения выполнения требований технического задания;
- измерения характеристик продукции и процессов ее создания, а также регистрацию данных о достигнутом качестве ПС и их компонентов;
- испытания, которые включают планирование, реализацию, оценку результатов и документирование испытаний и сертификации;
- приемку и испытания заказчиком для завершения контракта по разработке, инсталляции или обслуживанию ПС.
Кроме того, рекомендуется по согласованию с заказчиком регламентировать правила и технологию копирования, поставки, инсталляции, технического обслуживания и ремонта ПС. Независимо от этапов работ в технологии и системе качества должна быть определена деятельность по:
- формализации состава, содержания и процессам утверждения документации;
- управлению конфигурацией версий ПС и проведению изменений в программах и данных.
В целом, рекомендуется следующая последовательность этапов:
- Обследование.
- Разработка Спецификаций технических требований (и, если есть время, - Концепции проектируемой системы).
- Утверждение Технического задания.
- Системное проектирование (разработка ERD, Спецификации на программирование и пр.).
- Программирование (кодирование и генерация БД).
- Наполнение и тестирование.
- Документирование.
- Внедрение.
- Сопровождение.
При разработке внутрифирменной методологии ведения проектов были использованы, главным образом, опыт аналитиков фирмы и следующие стандарты:
- ГОСТ 34.602-89 (Техническое задание) [см. 2.1.2].
- IEEE Std 830-1993 (Спецификация требований к ПО) [см. 2.4.2].
- ISO 12207:1995 (ЖЦПО) [см. п. 2.2.3].
- DATARUN (ЖЦПО) [см. п. 2.3.1].
- ORACLE CDM (ЖЦПО) [см. п. 2.3.2].
- RUP (ЖЦПО) [см. п. 2.3.3].
Кроме того, были учтены некоторые положения других, приведенных в данном документе (раздел 2), стандартов, а также использована полезная информация из следующих публикаций: