Стадии и этапы разработки программ

ГОСТ 19.102—77 «Стадии разработки программ и программной документации»

В РФ жизненный цикл разработки ПО установлен стандартом ГОСТ 19.102—77 «Стадии разработки программ и программной документации» и содержит следующие стадии и этапы:

• 1. Техническое задание (ТЗ).
• 2. Эскизный проект (ЭП).
• 3. Технический проект (ТП).
• 4. Рабочий проект (РП).
• 5. Внедрение.

В табл. 2.7 показаны стадии разработки и этапы, их составляющие.

Таблица 2.7. Стадии и этапы жизненного цикла разработки (по ГОСТ 19.102—77)

Обоснование необходимости разработки программ

Постановка задачи; сбор исходных материалов;

выбор и обоснование критериев эффективности и качества;

обоснование необходимости проведения НИР

Выполнение научно-исследовательских работ (НИР)

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

Жизненный цикл IT проекта

определение требований к техническим средствам; обоснование принципиальной возможности решения поставленных задач

Разработка и утверждение технического задания

Определение требований к программе; разработка технико-экономического обоснования разработки программы;

определение стадий, этапов и сроков разработки программы и документации на нее; выбор языков программирования; определение необходимости проведения НИР на последующих стадиях; согласование и утверждение ТЗ

Окончание табл. 2.7

Предварительная разработка структуры входных и выходных данных;

уточнение методов решения задач;

разработка общего описания алгоритма решения задачи;

разработка технико-экономического обоснования

Разработка пояснительной записки; согласование и утверждение эскизного проекта

Уточнение структуры входных и выходных данных; разработка алгоритмов решения задач; определение формы представления входных и выходных данных;

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

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

разработка пояснительной записки; согласование и утверждение ТП

Программирование и отладка программ

Разработка программных документов в соответствии с требованиями ГОСТ 19.101—77

Разработка, согласование и утверждение программ и методики испытаний;

проведение предварительных государственных, межведомственных приемо-сдаточных и других видов испытаний;

корректировка ПО и программной документации по результатам испытаний

Подготовка и передача программы

Подготовка и передача ПО и программной документации для сопровождения и/или изготовления; оформление и утверждение акта о передаче ПО на сопровождение или изготовление; передача ПО в фонд алгоритмов и программ

Специалистам в области разработки ПО известно, что наиболее важными стадиями в жизненном цикле разработки являются начальные, так как ошибки, допущенные на них, требуют значительных затрат на исправление на конечных стадиях.

Стадии и этапы разработки программ

Источник: studref.com

Стадии и этапы разработки

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

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

Описание программы

Документ Описание программы ориентирован на документальное описание результирующего продукта разработки.

Этот документ создан на базе двух разных стандартов: ГОСТ 19.402-78 ЕСПД. «Описание программы» и ГОСТ 19.502-78 ЕСПД. «Описание применения. Требования к содержанию и оформлению», которые имеют между собой много общего и позволяют объединить их в одном общем документе, названном «Описание программы».

Описание программы может быть дополнено разделами и пунктами, взятыми и из стандартов для других описательных документов и руководств: ГОСТ 19.404-79 ЕСПД. «Пояснительная записка», ГОСТ 19.503-79 ЕСПД. «Руководство системного программиста», ГОСТ 19.504-79 ЕСПД. «Руководство программиста», ГОСТ 19.505-79 ЕСПД. «Руководство оператора» и т.п.

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

Основная часть документа должна состоять из вводной части и следующих разделов:

· состав и функции.

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

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

Например: Программа «Автоматизированное рабочее место разработчика САУ» предназначена для … реализована на …. Программа поддерживает …

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

Например: Программа предназначена для решения задач … Программа представляет собой ядро автоматизированного рабочего места …

Пользователь имеет возможность …, осуществить …, запустить …, проанализировать …, получить результаты анализа и обработки …, построить … и т.п.

В разделе » Описание логики » указывают:

-описание структуры программы и ее основных частей;

Например: В состав программы входят следующие компоненты:

· пользовательский интерфейс,

· модуль определения путей в графе,

· модуль расчета передаточной функции,

· модуль построения амплитудно- и фазочастотных характеристик,

· модуль построения реакции на полиномиальное воздействие,

· текстовый редактор).

-описание функций составных частей и связей между ними;

Например: Программа состоит из шести модулей: интерфейсный модуль; модуль определения …; модуль расчета …; модуль …и т.п.

Интерфейсный модуль построен на двух типах диалогов: диалог «вопрос — ответ» и диалог типа «меню». Интерфейсный модуль управляет …

Модуль определения … Он является …

Модуль расчета …и т.д.

-сведения о языке программирования;

Например: Программа написана на языке …с использованием компилятора …

-описание входных и выходных данных для каждой из составных частей;

Например: ВХОДНЫЕ ДАННЫЕ. Входными данными для программы является текстовый файл, описывающий расширенную матрицу инциденций графа исследуемой системы.

ВЫХОДНЫЕ ДАННЫЕ. Выходными данными являются:

· выводимая на экран графическая и текстовая информация (результаты анализа системы);

· файлы в одном из графических форматов — копии изображения построенных характеристик (АЧХ, ФЧХ и т.д.);

· текстовые файлы — отчеты о проведенных исследованиях;

· диагностика состояния системы и сообщения о всех возникших ошибках.

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

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

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

Например: Программа эксплуатируется на персональном компьютере (ПК) типа IBM PC/AT. Для работы в диалоговом режиме используется экран дисплея, клавиатура и манипулятор типа «мышь». Для поддержки графического режима необходим адаптер EGA (VGA). Входные данные хранятся на флоппи- и/или жестком дисках. Программа работает под управлением ОС …

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

Порядок вызова и загрузки системы.

Например: Загрузка программы осуществляется набором в командной строке DOS имени загрузочного модуля – SBM80N.EXE с возможным указанием имени файла данных.

Текст программы

Документ Текст программы выполняется в соответствии с требованиями ГОСТ 19.401-78 ЕСПД. «Текст программы. Требования к содержанию и оформлению», который устанавливает правила составления текста программы и его оформления.

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

Обязательным является составление информационной части – аннотации и содержания.

Основная часть документа должна состоять из текстов одного или нескольких разделов, которым даны наименования.

Текст каждого программного файла начинается с «шапки», в которой указывается:

· дата создания программы,

· дата последней модификации.

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

Источник: poisk-ru.ru

Жизненный цикл разработки ПО: основные этапы и модели

Чтобы разработать программное обеспечение, нужно использовать специальный алгоритм. Его называют SDLC (Software Life Cycle Model), или жизненный цикл ПО. Это своеобразная основа, которая делает процесс разработки последовательным и упрощает техническую поддержку масштабных IT-проектов. В статье расскажем, что такое SDLC, перечислим его основные этапы и модели.

Оптимизируйте маркетинг и увеличивайте продажи вместе с Calltouch

Что такое SDLC

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

Модели жизненного цикла программного обеспечения

Есть 5 моделей жизненного цикла программного обеспечения. Чаще используют каскадную, инкрементную и спиральную. V-образная и итеративная пользуются меньшим спросом в силу своей «неуниверсальности».

Каскадная

• стабильность требований в течение всего жизненного цикла ПО;
• составление пакета проектной документации на каждой стадии;
• согласованность действий;
• логичность и понятность каждого шага;
• простой алгоритм реализации модели;
• прозрачные и прогнозируемые сроки прохождения каждой фазы;
• возможность точно планировать и грамотно распределять бюджет;
• оптимизация трудозатрат.

Например, такая модель подойдет, если нужно создать усовершенствованную версию проекта или перенести готовый продукт на новую платформу.

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

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

Инкрементная

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

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

• Динамику разработки нужно постоянно контролировать и своевременно реагировать на любой регресс.
• Структура модели, как и любой другой системы, негативно реагирует на постоянное добавление новых компонентов. Если вы выбрали инкрементную модель, предусмотрите в бюджете расходы на рефакторинг.
• Жизненный цикл ПО время от времени прерывается, и на то, чтобы заново собрать структуру воедино и продолжить разработку уходит много ресурсов.

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

Бизнес

Что такое коммерческие расходы и как их учитывать

Что такое коммерческие расходы и как их учитывать

Спиральная

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

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

• Возможность быстро показать пользователям готовый продукт и в процессе его доработки до итоговой версии устранить недочеты.
• Гибкость проектирования за счет сочетания преимуществ каскадной и инкрементной моделей, которые не исключают, а органично дополняют друг друга.
• Создание надежной и устойчивой системы за счет устранения слабых мест в ходе многочисленных доработок.
• Получение качественной обратной связи от пользователей.

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

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

V-образная

По сути, это та же каскадная модель, только более усовершенствованная. От прототипа она отличается тем, что тестирование проводят на каждом этапе. Это позволяет свести к минимуму количество ошибок в архитектуре программного обеспечения.

Основной минус – такой же, как и у классической каскадной модели – нет права на ошибку. Если на каком-то из этапов разработчики допустили недочет, его исправление окажется очень трудоемким и дорогим.

Применение V-модели оправдывает себя при разработке надежных и точных продуктов. Например, систем видеонаблюдения.

Итеративная

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

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

Когда пробная версия готова, вы тестируете ее самостоятельно и предлагаете попробовать ее использовать друзьям, коллегам, партнерам – тем, чье мнение для вас авторитетно.

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

Вы понимаете, что продукт стоит того, чтобы его доработать, предложить более широкой аудитории и начать на нем зарабатывать деньги. И уже на этом этапе целесообразно писать подробное ТЗ для разработчиков, чтобы они устранили выявленные баги, добавили полезные функции, адаптировали продукт к требованиям рынка.

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

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

Этапы разработки жизненного цикла ПО на примере каскадной модели

Выделяют 6 этапов реализации каскадной модели жизненного цикла ПО. Это основные шаги, которые применяют при планировании, разработке, тестировании и развертывании программного обеспечения.

Импровизировать и менять последовательность действий в данном алгоритме нельзя – это чревато последствиями: от неоправданного увеличения трудозатрат до серьезных сбоев в командной работе и финансовых потерь.

Согласованность и целесообразность всех действий в рамках разработки ПО обусловлена жесткой последовательностью этапов и их влиянием друг на друга.

Идея. Допустим, вы хотите открыть интернет-магазин одежды. Это и есть идея, для воплощения которой нужна команда специалистов: разработчик, дизайнер, оптимизатор, специалист по юзабилити, маркетолог, копирайтер.

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

Анализ и разработка требований. На этом этапе в процесс включаются тестировщики. Их основные задачи – собрать, проанализировать, систематизировать и задокументировать требования к создаваемому ПО. Тестировщики озвучивают свое видение продукта, корректируют процесс, выявляют возможные противоречия.

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

Проектирование. Этот этап нужен для того, чтобы ответить следующие вопросы:

• Как именно я и моя команда будем добиваться поставленных целей?
• Какие технологии будем использовать?
• Сколько времени займет выполнение пула поставленных задач?
• Как оптимизировать трудозатраты?
• Как добиться максимальной производительности команды, сделать ее работу слаженной и продуктивной?
• Какой бюджет потребуется?

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

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

Виджеты Calltouch

• Увеличьте конверсию сайта на 30%
• Обратный звонок, промо-лендинги, формы захвата, мультикнопка, автопрозвон форм

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

Другие члены команды тем временем доводят до логического завершения дизайн, оптимизаторы составляют технические задания на тексты, копирайтеры готовят оптимизированный контент, контент-менеджер наполняет сайт товарами.

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

Этот цикл повторяется до тех пор, пока количество багов не станет минимальным или равным нулю. У каждого ресурса есть свой порог, после которого можно прекратить его тестировать.

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

Запуск, аналитика и сопровождение. Как только вы поймете, что в ПО не осталось серьезных дефектов и оно полностью готово к запуску, пришла пора официально выпустить готовый качественный программный продукт.

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

Пользователи могут столкнуться с пострелизными багами и обратиться в техподдержку в нерабочее время. Чтобы не упустить ни одного обращения и показать клиентоориентированность компании, подключите обратный звонок Calltouch. Клиент оставит заявку, а система свяжет с ним специалиста, как только начнется рабочий день.

Виджет обратного звонка для сайта

• Повысьте конверсию сайта на 30%
• Новым клиентам 50 минут в подарок

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

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

Бизнес

Кто такая Сири и что она умеет: обзор возможностей голосового помощника

Кто такая Сири и что она умеет: обзор возможностей голосового помощника

Коротко о главном

При выборе модели жизненного цикла ПО ориентируйтесь на особенности продукта, который вы хотите получить, и потребности целевой аудитории. Для реализации сложных многоступенчатых систем, простых продуктов и их новых версий подходят разные модели SDLC. Грамотно выбрав вид алгоритма, вы запустите действительно успешный продукт, который будет востребован у пользователей, и потратите разумное количество времени и денег на воплощение идеи.

Источник: www.calltouch.ru