В соответствии с ГОСТ 19.102—77 допускается исключать стадию ЭП, а в технически обоснованных случаях — стадии ЭП и ТП. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком. Это позволяет разумно построить проект конкретной разработки (ход проекта также является объектом проектирования).
Пример 1. Разработка наукоемкой подпрограммы может вестись по следующим стадиям:
• ТЗ (ТЗ основное плюс ТЗ на отдельную НИР);
• ожидание результатов НИР, выполняемой в другой организации специалистами-математиками (срок от месяца до нескольких лет);
• РП (около месяца);
• внедрение.
Пример 2. Требуется разработать программное изделие средней или большой сложности. При средней сложности изделия необходимо проведение ТП, а при большой сложности — и ЭП, и ТП. В отличие от примера 1 в данном случае ТЗ может не содержать законченных требований.
Пример 3. Требуется создать программные средства, автоматизирующие отдельные виды работ. Разработка такого проекта может проводиться по следующим стадиям:
• ТЗ;
• ЭП с НИР по исследованию существующих программных средств, автоматизирующих выполнение отдельных видов работ;
• РП по разработке только документации без реализации каких-либо программ, если НИР показала, что можно обойтись только существующими программными средствами;
• внедрение.
Пример 4. Разработка таких информационных систем, как САПР или АСУ должна осуществляться в соответствии с соответствующими стандартами. ТП САПР или АСУ может содержать технические задания на разработку отдельных программных изделий. Как правило, такие ТЗ очень конкретны. На этапе РП САПР или АСУ сначала ведется контроль над разработкой программных изделий по всем необходимым для этого стадиям разработки программных изделий, затем проводится совместная проверка всех разработанных программ.
Обычно основанием для заключения договора между заказчиком и исполнителем служит гарантийное письмо заказчика. На основании гарантийного письма составляется договор. Обязательным приложением к договору является ТЗ.
Некоторые отечественные и зарубежные источники предлагают выделять следующие этапы:
1) анализ требований, предъявляемых к системе (системный анализ). (Обычно проводится на основе первичного исследования потоков информации при традиционном проведении работ с фиксацией видов этих работ и их последовательности.);
2) определение целей, достигаемых разрабатываемыми программами;
3) выявление аналогов, обеспечивающих достижение подобных целей, их достоинств и недостатков;
4) постановка задачи на разработку новых программ, определение внешних спецификаций (т. е. описаний входной и выходной информации, а иногда и их форм) и способов (алгоритмов, методов) обработки информации;
5) оценка достижения целей разработки (Далее, при необходимости, этапы 1–5 могут быть итеративно повторены до достижения удовлетворительного облика изделия с описанием выполняемых им функций и некоторой ясностью реализации его функционирования.);
6) рассмотрение возможных вариантов структурного построения программного изделия: или в виде нескольких программ, или нескольких частей одной программы; результатом этой работы являются варианты архитектуры программной системы и (или) требования к структуре отдельных программных компонент; организация файлов для межпрограммного обмена данными;
7) разработка окончательного варианта архитектуры системы и разработка окончательной структуры программных компонент;
8) составление и проверка спецификаций модулей;
9) составление описаний логики модулей;
10) составление окончательного плана реализации программ;
11) кодирование и тестирование отдельных модулей и совокупности готовых модулей до получения готовой программы;
12) комплексное тестирование;
13) разработка эксплуатационной документации на программу;
14) проведение приемо-сдаточных и других испытаний;
15) корректировка программ по результатам испытаний;
16) окончательная сдача программного изделия заказчику;
17) тиражирование программного изделия;
18) сопровождение программы.
Современные технологии проектирования программного обеспечения (ПО) направлены на частичную автоматизацию этапов и на совмещение их во времени с целью сокращения сроков выполнения проектов.
В литературных источниках применяются наименования этапов, которые охватывают ряд приведенных этапов и по времени охватывают даже несколько стадий. Например, этап разработки программы.
1.9. ТИПОВЫЕ ОШИБКИ ОБУЧАЕМЫХ ПРИ СОСТАВЛЕНИИ ТЕХНИЧЕСКОГО ЗАДАНИЯ
В приложении 2 приведен пример выполнения учебного технического задания. В примере опущены: лист утверждения, титульный лист и приложения.
Главным, что отличает одно ТЗ от другого, является- смысл требований. Все требования оформляются предложениями с использованием оборотов «должно», «требуется обеспечить», «необходимо выполнить». Рекомендуется требования оформлять в форме нумерованных абзацев. Это позволит давать на них ссылки.
Типовыми ошибками являются написания неконкретных требований, которые никого ничему не обязывают. Требования не должны быть противоречивыми. Поэтому дублирование одних и тех же по смыслу требований разными словами в разных местах текста часто приводит к невозможности реализации изделия из-за неоднозначности их понимания заказчиком и исполнителем.
Ниже приведены типовые ошибки обучаемых при написании требований к функциональным характеристикам:
• непонимание термина «функциональные характеристики» (Смысл этого термина характеризуется следующим предложением: «Проектируемый завод в нормальном режиме работы должен обеспечить выпуск за одну 8-часовую смену не менее 40 пропашных тракторов». Эта фраза содержит как назначение проектируемого объекта — завода, так и то, что выпускает завод и при каких ограничениях. Применительно к программам, для правильного написания требований к функциональным характеристикам необходимо сторонними глазами будущего пользователя рассмотреть, что делает полезного программное изделие и при каких ограничениях.);
• описание требований к функциональным характеристикам всеобщего, универсального объекта (если по конкретным требованиям можно реализовать целый спектр изделий, то они не конкретны);
• написание заведомо нереализуемых требований.
В приведенном в приложении 2 примере выполнения учебного технического задания отсутствуют приложения. Само техническое задание содержит требования к весьма простому программному изделию, поэтому ряд разделов технического задания написаны как бы для более сложного изделия.
1.10. МОДЕЛИРОВАНИЕ И ПРОГРАММИРОВАНИЕ. ПОНЯТИЕ СПЕЦИФИКАЦИЙ
Один объект или система может выступать в роли модели другого объекта или системы, если между ними установлено сходство в каком-то смысле. Моделью системы (или какого-либо другого объекта или явления) может быть формальное описание системы, в котором выделены основные объекты, составляющие систему, и отношения между этими объектами.
Построение моделей — широко распространенный способ изучения сложных объектов и явлений. В модели опущены многочисленные детали, усложняющие понимание. Моделирование широко распространено в науке, технике и программировании.
Модели помогают проверить работоспособность разрабатываемой системы на ранних этапах ее разработки; общаться с заказчиком системы, уточняя его требования к системе; вносить (в случае необходимости) изменения в проект системы (как в начале ее проектирования, так и на других фазах ее жизненного цикла); передавать проект иным исполнителям, например кодировщикам, поскольку сам проект является моделью проектируемой программы.