Технология разработки программного обеспечения

1Технология разработки программного обеспечения. Основные этапы на примере классического жизненного цикла.

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

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

ПО – комплекс программ, предназначенный для решения задачи.

Жизненный цикл ПО – отрезок времени от момента возникновения необходимости в создании ПО до момента снятия его с эксплуатации.

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

1.разработка;

2.эксплуатация;

3.сопровождение.

На фазе сопровождения, как правило, выполняются следующие виды работ:

1.расширение функциональных возможностей ПО;

2.модификация уже существующих функций;

3.модификация ПО, связанная с модификацией аппаратного обеспечения;

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

При проведении разработки чѐтко выделяют следующие этапы:

1.определение требований к ПО, которое предусматривает сбор необходимой информации.

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

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

4.программирование (кодирование).

5.тестирование и отладка. Тестирование – процесс выявления факта наличия ошибок в программе. Отладка – тестирование + диагностика и локализация ошибок + устранение ошибок.

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

Модели жизненного цикла ПО:

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

●Итерационная модель - предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определѐнную интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта.

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

2Описание технического задания по ГОСТ.

Всоответствии с этим стандартом в техническое задание включаются следующие разделы:

1.введение;

2.основание для разработки;

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

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

5.требования к документации;

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

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

8.порядок контроля и приѐмки

9.приложение.

Введение:

●наименование;

●краткая характеристика в области применения ПО.

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

Основание для разработки:

●наименование документа, на основании которого ведѐтся разработка;

●организация, утвердившая данный документ;

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

Таким документом может служить план, приказ, договор и т.д.

Назначение разработки:

описание функционального и эксплуатационного назначения данной системы с указанием категории еѐ пользователей.

Требования к программе или к программному изделию.

Этот раздел должен включать следующие подразделы:

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

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

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

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

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

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

●требования к транспортированию и хранению.

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

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

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

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

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

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

Вразделе требования к маркировке и упаковке указываются способы маркировки и упаковки ПО.

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

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

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

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