Стандарты, стадии и этапы разработки программ
Стандарты давно используются в технике и программировании. Создание сложной системы немыслимо без стандартов. Они нужны для борьбы с хаосом и неразберихой, но вместе с этим стандарт не должен быть слишком «узким» и мешать техническому прогрессу.
Государственные стандарты отслеживают тенденции развития программирования и дают обязательные рекомендации по их соблюдению. Сегодня используются обозначения ГОСТ (государственный стандарт) со времен Советского Союза и СТБ (стандарт Беларуси) новые стандарты Республики Беларусь. Помимо государственных стандартов действуют отраслевые стандарты (ОСТ), стандарты предприятий (СТП).
Группа стандартов ГОСТ «Единая система программной документации» (ЕСПД) претерпела мало изменений с момента ее создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. При этом она до настоящего времени никогда не затрудняла новаций.
Помимо вышеизложенных стандартов де-юре имеются стандарты де-факто. Ряд стандартов устанавливается де-факто ведущими фирмами-разработчиками программ и вычислительной техники. Стандарты де-факто появляются на основе идей какой-то широко известной разработки. Выгодно делать продукты в стиле разработки какой-то фирмы, так как пользователи уже имеют навыки работы с меню в стиле «Lotus», электронными таблицами, текстовыми редакторами. Обычно стандартом де-факто определяются используемые операционные системы, трансляторы с языков программирования, организация файлов и средний уровень качества, достигаемый по окончании тестирования программ. Конкретному разработчику выгодно следовать таким стандартам.
|
|
|
В области программирования общепризнанной ведущей организацией по разработке стандартов является институт ANSI (Американский национальный институт стандартов). Данный институт является лидером по установке стандартов языков программирования, кодовых таблиц клавиш и символов, выводимых на экран, и еще многих других. Необходимо также отметить стандарты ISO.
К сожалению, самое благородное дело стандартизации – достижение всеобщей унификации и взаимозаменяемости – может также стать тормозом развития. Вводя новый стандарт, надо учитывать последствия ввода, особенно если стандарт является опережающим и опережает практику развития или если стандарт является слишком «узким» и тормозит эволюцию прогресса. Во всем мире руководствуются следующим отношением к стандартам: или полностью им следуй, или делай свой собственный стандарт. Стандарты дают дополнительные ограничения.
Программист должен уметь не только использовать готовые стандарты, но и разрабатывать новые. Так, например, правила однотипного оформления исходного текста программы определяются стандартом проекта, который может быть изменен при начале разработки нового проекта. Однако в течение выполнения одного проекта оформление всех частей программы должно быть однотипным. Поэтому зачастую перед началом нового проекта конкретным программистам следует разрабатывать свои стандарты, которые не нарушают ГОСТ, ОСТ и СТП и действуют в пределах конкретного проекта.
|
|
|
«ГОСТ 19.102-77. Единая система программной документации. Стадии разработки» регламентирует стадии и этапы программных разработок в течение всего жизненного цикла. Данный стандарт сформировался на основе анализа удачных и неудачных программных разработок и содержит основные рекомендации по проведению новых разработок. Стандарт уже пережил несколько технологий программирования. При этом, практически не изменяясь, он не являлся тормозом прогресса. Помимо наименований стадий и этапов проектирования ГОСТ 19.102-77 фактически содержит описание аналитико-синтетического эвроритма (алгоритма действий проектировщика с использованием методов анализа и синтеза) по временным этапам проекта.
|
|
|
Стадия проекта – одна из частей процесса создания программы, установленная нормативными документами и заканчивающаяся выпуском проектной документации, содержащей описание полной, в рамках заданных требований, модели программы на заданном для данной стадии уровне, или изготовлением программ. По достижении окончания стадии заказчик имеет возможность рассмотреть состояние проекта и принять решение по дальнейшему продолжению проектных работ. Например, заказчик может принять решение о продолжении работ по одному из согласованных вариантов.
Этап проекта — обычно часть стадии проекта, выделенная по соображениям единства характера работ и (или) завершающего результата или специализации исполнителей. Иногда выделяют этапы (фазы), которые охватывают несколько стадий. Например, этап проектирования программы включает стадии ЭП и ТП. Описания этапов регламентируют порядок выполнения отдельных видов работ для достижения стадии. Одни и те же виды работ могут продолжаться ряд этапов.
Программный документ «Техническое задание» (ТЗ) помимо основных требований к программному изделию содержит проект порядка взаимодействия заказчика и исполнителя по окончании конкретных этапов, т. е. перечень необходимых стадий и этапов и требований к их выполнению. ТЗ может сразу не устанавливать всех требований, которые могут быть уточнены и согласованы с заказчиком на последующих стадиях. Однако сама возможность изменения требований должна закладываться в ТЗ. В ТЗ определяется стратегия выполнения проекта.
|
|
|
«Эскизный проект» (ЭП), как правило, необходим для разработки нескольких альтернативных вариантов реализации будущего изделия и уточнения требований на основе их анализа. Степень проработки при этом должна быть достаточной лишь для достижения возможности сравнения вариантов.
«Технический проект» (ТП) выполняется для получения однозначного описания конечного (оптимального) варианта построения программного изделия и порядка его реализации.
«Рабочий проект» (РП) необходим для реализации изделия в соответствии с ранее намеченным планом.
Стадия «Внедрение» необходима для размножения программной документации в нужном количестве, обучения пользователей, помощи в освоении программы, сопровождения программы.
Научно-исследовательская работа (НИР) может быть самостоятельным этапом. НИР в основном проводится для выявления последних научных достижений с целью их использования в проекте, проверки реализуемости изделия и уточнения отдельных его характеристик.
В соответствии с ГОСТ 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) сопровождение программы.
Современные технологии проектирования программного обеспечения направлены на частичную автоматизацию этапов и на совмещение их во времени с целью сокращения сроков выполнения проектов.
В литературных источниках применяются наименования этапов, которые охватывают ряд приведенных этапов и по времени охватывают даже несколько стадий. Например, этап разработки программы.
Выводы
• Проектирование — высокоинтеллектуальный процесс. Для понятия теории проектирования необходимо оперировать множеством терминов и определений, такими как проектная ситуация, технология, оптимизация программных разработок. Все это говорит о необходимости тщательно подходить к изучению словарного аппарата теории проектирования.
• Разработка архитектуры – это процесс разбиения большой системы на более мелкие части. Процесс разработки архитектуры – этап, необходимый при проектировании систем или комплексов, но необязательный при создании программы. Если внешние спецификации (экранные формы, организация файлов...) описывают программную систему с точки зрения пользователя, то следующий шаг проектирования состоит в разработке архитектуры, а за ним следует проектирование структуры каждой программы.
• Программы в основном представляют собой сложные системы из миллионов машинных инструкций. Сложность определяется четырьмя основными причинами: сложностью задачи; сложностью управления процессом разработки; сложностью описания поведения отдельных подсистем; сложностью обеспечения гибкости конечного программного продукта.
• Одной из важнейших составляющих успешного проектирования является системный подход, предусматривающий всестороннее исследование сложного объекта.
• При создании и развитии ПО рекомендуется применять следующие общесистемные принципы: включения; системного единства; развития; комплексности; информационного единства; совместимости; инвариантности.
• Необходимо помнить, что проектирование неотъемлемо от различных стандартов (ГОСТ, ANSI, проекта) и их следует соблюдать как при оформлении документации, так и для унификации вашего проекта.
• Программы создаются, эксплуатируются и развиваются во времени, проходя свой жизненный цикл. Характерная особенность жизненного цикла ПО — отсутствие этапа утилизации.
• В процессе выполнения проекта предусматриваются отдельные моменты времени, которые характеризуются законченным оформлением результатов всех работ, выполненных разработчиками до данного момента. Согласно ГОСТ возможны следующие стадии разработки: ТЗ; ЭП; ТП; РП; внедрение. Возможны также и нестандартные этапы, и стадии. Набор этапов и стадий отражает результаты проектирования самого процесса проектирования.
Контрольные вопросы
1. Дайте определения: программная продукция, программное обеспечение, информационная и автоматизированная система.
2. Какими основными причинами определяется сложность задачи?
3. Дайте определения: проектирование, проект, проектная задача.
4. Что такое метод проектирования и методики проектирования?
5. Какими свойствами характеризуется алгоритм?
6. Что такое эвристика? В чем состоит схожесть и различие алгоритма и эвроритма?
7. Что такое архитектура программ?
8. Какие виды анализа используются при системном подходе?
9. Что такое принцип совместимости?
10. Для чего необходима стандартизация проектирования и программирования?
11. Назовите основные этапы жизненного цикла программных изделий.
12. Назовите основные стадии и этапы разработки программ по ГОСТ 19.102-77.
Дополнительная литература и источники
1. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
2. IEEE Std 1074-1995, IEEE Standard for Developing Software Life Cycle Processes.
3. «Руководство к своду знаний по программной инженерии». The Guide to the Software Engineering Body of Knowledge, SWEBOK, IEEE Computer Society Professional Practices Committee, 2004.
4. «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.
Дата добавления: 2018-05-02; просмотров: 895; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!