Лекция 16. Государственные стандарты разработки программных средств.

ГОСТ ЕСПД

Этапы и процессы, а также примерные результаты по каждому этапу определены в стандартах (международный – ISO 12207: 1995 “Information Technology – Software Life Cycle Process”; российский ГОСТ ЕСПД 19.001-77 — 19.604-78).

Этапы работ (ГОСТ 19.102-77)

Стадии разработки, этапы и содержаниеработ должны соответствовать следующим:

Стадии разработки	Этапы работ	Содержание работ
1. Техническое задание	Обоснование необходимости разработки программы	Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ
Научно-исследовательские работы	Определение структуры входных и выходных данных. Предварительный выбор методоврешения задач. Обоснование целесообразности применения ранее разработанных программ. Определенже требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи
Разработка и утверждение технического задания	Определение требований к программе. Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на нее. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания
2. Эскизный проект	Разработка эскизного проекта Утверждение эскизного проекта	Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи. Разработка технико-экономического обоснования Разработка пояснительной записки. Согласование и утверждение эскизного проекта
3. Технический проект	Разработка технического проекта Утверждение технического проекта	Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта
4. Рабочий проект	Разработка программы Разработка программной документации   Испытания .программы	Программирование и отладка программы. Разработка программных документов в соответствии с требованиями ГОСТ 19.101—77 Разработка, согласование и утверждение программы и методики испытаний. Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний
5. Внедрение	Подготовка и передача программы	Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ

Примечания:

1. Допускается исключать вторую стадию разработки, а в технически обо­снованных случаях - вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.

2. Допускается объединять исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.

16.1.2 Техническое задание (ГОСТ 19.201-78)

Техническое задание должно содержать следующие раз­делы:

· введение;

· основания для разработки;

· назначение разработки;

· требования к программе или программному изделию;

· требования к программной документации;

· технико-экономические показатели;

· стадии и этапы разработки;

· порядок контроля и приемки;

· в техническое задание допускается включать приложения.

В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить но­вые разделы или объединять отдельные из них.

Содержание разделов

2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или програм­мное изделие.

2.2. В разделе «Основания для разработки» должны быть ука­заны:

· документ (документы), на основании которых ведется разработка;

· организация, утвердившая этот документ, и дата его утверждения.

· наименование и (или) условное обозначение темы разработка.

2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

2.4. Раздел «Требования к программе или программному из­делию» должен содержать следующие подразделы:

· требования к функциональным характеристикам;

· требования к надежности;

· условия эксплуатации;

· требования к составу и параметрам технических средств;

· требования к информационной и программной совместимости;

· требования к маркировке и упаковке;

· требования к транспортированию и хранению;

· специальные требования.

2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, времен­ным характеристикам и т. п.

2.4.2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т. п.).

2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т. п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.

2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

2.4.5. В подразделе «Требования к информационной и. программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средст­вам, используемым программой. При необходимости должна обеспечиваться защита информации и программ.

2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

2.5а. В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.

2.5. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.

2.6. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.

2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы,

2.8. В приложениях к техническому заданию, при необходимости, приводят:

· перечень научно-исследовательских и других работ, обосновывающих разработку;

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

· другие источники разработки.

Комментарий к ГОСТу

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

Раздел «Основания для разработки» мы пропускаем, а название и шифр темы (если такой есть) указываем в разделе «Назначение…». Там же кратко указывается, для чего выполняется проект, например: автоматизировать прием экзамена по технологии программирования, - двумя-тремя фразами.

Основным разделом ТЗ должен быть раздел изложения требований к программному продукту. Обязательно изложить в техническом задании следующие требования:

· требования к функциональным характеристикам;

· требования к надежности;

· требования к составу и параметрам технических средств;

· требования к информационной и программной совместимости;

· требования к хранению;

· специальные требования.

Требования к функциональным характеристикам – это достаточно подробное изложение того, что должен делать программный продукт (не описывая, как это будет реализовано).

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

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

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

Требования к хранению – это предполагаемый носитель готового программного продукта, с которого будет производиться установка.

16.1.2.3 Западные авторы о требованиях

Майерс [28]:

Программные продукты делятся на 3 категории:

1. Независимый от пользователя проект – требования определяет разработчик; примеры – современные программные продукты, выпускаемые западными фирмами; из российских – система 1С.

2. Управляемый пользователем проект – требования формирует заказчик; примеры – правительственные заказы (космонавтика).

3. Контролируемый пользователем проект; требования формируются совместно; примеры – многочисленные АСУ.

Кроме требований обязательным условием успешного проекта является постановка целей. Практика показывает, что самой большой ошибкой проекта является отсутствие явной формулировки целей. При постановке целей работа обычно идет лучше. Цели – не требования. Цели - это явно сформулированное стремление обеспечить заданные качества программного продукта в процессе разработки. Примером может служить цель обеспечить надежность и эффективность проектируемой системы. Цели часто противоречат друг другу. Майерс[28] определяет цели следующим образом: «Цели – это конкретные ориентиры для программного продукта. Процесс постановки целей – это процесс принятия компромиссных решений». Следующая цитата из [28] поясняет эту мысль: «Программное обеспечение State Farm обслуживает порядка 15 000 000 владельцев полисов и обрабатывает страховые премии на сумму порядка 2.3 миллиарда долларов ежегодно. В условиях, когда от аккуратности системы зависит так много долларов и людей, надежность должна предшествовать эффективности. Кроме того, … модификации программы – постоянный процесс, образ жизни. Поэтому удобство сопровождения также более важно, чем эффективность».

Майерс[28] делит множество целей на несколько групп и соотносит с главной целью – обеспечение надежности. Эти цели должны быть сформулированы явно, и разработчик обычно должен отдавать себе отчет, что не все цели могут быть в равной мере достигнуты. Поэтому, как сказано выше, приходится принимать компромиссное решение. В том смысле, как понимает цели Майерс, многие (но не все!) из них можно сформулировать в виде требований. Рассмотрим некоторые из них.

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

Адаптируемость –мера простоты расширения и модификации продукта. Как это ни удивительно, но свойство адаптируемости, по мнению Майерса, хорошо согласуется с надежностью. Очевидно, что адаптируемость может часто формулироваться как одно из требований к системе (если заказчик это понимает!).

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

Удобство сопровождения –мера затрат времени и средств на исправление ошибки в работающей системе. Эта цель тесно связана с адаптируемостью и хорошо согласуется с надежностью.

Безопасность -это мера вероятности несанкционированного доступа к данным. Понятно, что обеспечение этой цели только повышает надежность системы. Кстати, эта цель тоже часто формулируется в виде явного требования.

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

В остальных случаях к эффективности необходимо относиться разумно. Приведенная выше цитата демонстрирует правильный подход к проблеме эффективности. Требования к эффективности очень редко формулируются явно, если только разрабатываемая система не является системой реального времени. С точки зрения Майерса[28], «следует считать, что всякий разработчик программного обеспечения, жертвуя надежностью ради эффективности, поступает безответственно».

Майерс в качестве целей упоминает ещё стоимость продукта, календарный план и документирование. Поскольку ГОСТ ЕСПД явно задает стандарты для этих вещей, мы не будем рассматривать их в качестве целей.

Литература

Рейнгольд Э. и др. Комбинаторные алгоритмы: теория и практика.

Ахо А., Хопкрофт Дж., Ульман Дж. Построение и анализ вычислительных алгоритмов.

Гудман С., Хидетниеми С. Введение в разработку и анализ алгоритмов.

Вирт Н. Алгоритмы + структуры данных = программы.

Гэри М., Джонсон Д. Вычислительные машины и труднорешаемые задачи.

Niemann,Tomas. Сортировка и поиск: Рецептурный справочник Перевод с английского П.Н.Дубнер ([email protected]).

СибуяМ., Ямамото Е. Алгоритмы обработки данных.

Aho, Alfred V. and Jeffrey D. Ullman [1983]. Data Structures and Algorithms. Addison-Wesley, Reading, Massachusetts.

Cormen, Thomas H., Charles E. Leiserson and Ronald L. Rivest [1990]. Introduction to Algorithms. McGraw-Hill, New York.

Knuth, Donald E. [1998]. The Art of Computer Programming, Volume 3, Sorting and Searching. Addison-Wesley, Reading, Massachusetts.

Pearson, Peter K. [1990]. Fast Hashing of Variable-Length Text Strings. Communications of the ACM, 33(6):677-680, June 1990.

Pugh, William [1990]. Skip Lists: A Probabilistic Alternative to Balanced Trees. Communications of the ACM, 33(6):668-676, June 1990.

Глоссарий

Term	Термин
sort by insertion	сортировка вставками
replacement selection	выбор с замещением
polyphase merge sort	многофазное слияние
array	массив
linked list	линейный список
comparison	сравнение
in-place	на месте (без дополнительных массивов)
stable sort	устойчивая сортировка
external sort	внешняя сортировка
underflow	вырождение
overflow	переполнение
red-black tree	красно-черное дерево
B-tree	Б-дерево
skip list	слоёный список
rotation	вращение

[1] Линус !!!Торвальдсен!!! в одиночку создал ядро операционной системы Linux.