Приведем наиболее важные положения стандарта (полностью см. в [10]).
К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ. Виды программных документов и их содержание:
· Спецификация - состав программы и документации на нее.
· Ведомость держателей подлинников - перечень предприятий, на которых хранят подлинники программных документов.
· Текст программы - запись программы с необходимыми комментариями.
· Описание программы - сведения о логической структуре и функционировании программы.
· Программа и методика испытаний - требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля.
· Техническое задание - назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний.
· Пояснительная записка - схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений.
· Эксплуатационные документы - сведения для обеспечения функционирования и эксплуатации программы. Содержат:
IEEE Std 830-1993 - IEEE Recommended Practice for Software Requirements Specifications (ANSI). «Рекомендации по разработке спецификаций требований программного обеспечения».
Стандарт IEEE 830 является признанным разработчиками как не только формально обязательный, но и практически полезный при разработке спецификаций (близко к ТЗ).
Кратко основные полезные моменты стандарта.
1. Определены ключевые требования «хорошей спецификации»:
· Unambiguous (недвусмысленность) - отсутствие лексических, синтаксических и семантических ошибок.
· Complete (полнота) - должны быть описаны все значимые области требований.
· Verifiable (проверяемость) - должны содержаться только те требования, которые могут быть численно измерены.
· Consistent (целостность) -не должно быть конфликтов требований.
· Modifiable (модифицируемость)- спек должен быть легким в использовании и организации ссылок между требованиями.
· Traceable (трассируемость)- спек должен позволять пошагово отслеживать (трассировать) от требований до предудущих принятых решений, от документов расширяющих спек (проектировка и т.д.) к требованиям спека.
· Usable (возможность применения)- спек должен без излишних деталей описывать весь жизненный цикл системы.
2. Определено прототипирование как метод разработки требований к системе.
3. Даны образцы структуры спеков.
Заметим, отсутствует описание спека от понятия use case, широко применяемого в UML. Близкое по смыслу описание дается от понятия stimulus (отписание от проблем и задач пользователя).
IEEE Std 1074-1991 - IEEE Standard for Developing Software Life Cycle Processes (ANSI). «Процессы жизненного цикла для развития программного обеспечения». Описывает этапы жизненного цикла программного обеспечения и соответствующие входы [и выходы, т.е. отчетные документы] для каждого этапа.
На данный момент самой новой версией стандарта является IEEE Std 1074.1-1995.
Стандарт охватывает полный жизненный цикл ПС, в котором выделяются шесть крупных базовых процессов. Эти процессы детализируются 16 частными процессами. В последних имеется еще более мелкая детализация в совокупности на 65 процессов-работ.
Содержание каждого частного процесса начинается с описания общих его функций и задач и перечня действий (работ) при последующей детализации. Для каждого процесса в стандарте представлена входная и результирующая информация о его выполнении и краткое описание сущности процесса.
В стандарте внимание сосредоточено преимущественно на непосредственном создании ПС и на процессах предварительного проектирования. В приложении представлены четыре варианта адаптации максимального состава компонентов ЖЦ ПС к конкретным особенностям типовых проектов.
Хотя основные процессы близки к описанным в стандарте ISO 12207, общая архитектура и детализация частных процессов и работ в данном стандарте значительно отличается. Процессы непосредственного создания ПС и его поддержки в стандарте представлены наибольшим числом частных процессов (около 70%), начинающимся с разработки требований к ПС и завершающимся приемо-сдаточными испытаниями, проводимыми заказчиком или пользователем.
ISO 12207:1995 – ISO Standard for Software life cycle processes [см. 13, 18].
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.
Очень важное замечание стандарта: процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.)
В отличие от Oracle CDM стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.
В стандарте рассматриваются следующие этапы:
Стандарт регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах:
В стандарте расшифровано свыше 220 работ и комментариев к ним. Стандарт состоит из 7 разделов и 4 приложений.
Стандарт принципиально не содержит конкретные методы действий, тем более - заготовки решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить услуги и задачи, включенные в процессы, не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт.
Конкретность пользы стандарта в том, что он содержит наборы задач, характеристик качества, критериев оценки и др., дающие всесторонний охват проектных ситуаций. Например, при выполнении анализа требований к системе предусматривается, что:
Далее, при выполнении анализа требований к ПО предусмотрено 11 классов характеристик качества, которые используются позже при гарантировании качества. При этом разработчик должен установить и документировать как требования к программному обеспечению:
а) функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена;
б) внешние связи (интерфейсы) с единицей программного обеспечения;
в) требования квалификации;
г) спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;
д) спецификации защищенности, включая спецификации, связанные с компрометированием точности информации;