Технология разработки ПО

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

набор включает 9 процессов:
1. Исследование;
2. Управление;
3. Анализ;
4. Проектирование;
5. Кодирование;
6. Тестирование;
7. Ввод в действие;
8. Сопровождение;
9. Снятие с эксплуатации.
Процессы классического набора фактически являются подмножеством стандартного, выступая там как процессы или действия процессов.
Стандартный набор – совокупность процессов из ISO/IEC 12207:1999 «Информационная технология – Процессы жизненного цикла ПО».
Стандартный набор включает 3 группы процессов:
основные,
вспомогательные,
организационные процессы.

заключается в появлении и превращении возникшей идеи в определённую концепцию

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

в принятии решений по правильной организации имеющихся ресурсов проекта в

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

называемой управление проектами (букв. проектный менеджмент).
Цель проекта описывает, какие

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

ЖЦ, который заключается в уточнении, формализации и документировании требований заказчика.

Основной вопрос, который решается здесь – «ЧТО должен делать будущий продукт?» В этом процессе наиболее важным является понимание понятия «требование». Существует несколько точек зрения на понятие «требование».

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

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

случае спецификация – достаточно полное и точное формальное описание работы,

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

ПрО – ключевой элемент этого процесса. Цель моделирования – понимание

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

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

вопрос, который решается здесь – «КАК продукт будет удовлетворять полученным требованиям?». В этом процессе наиболее важным является представление разрабатываемого ПО (как единого целого) в виде системы.

структуры, проектирование «в большом», архитектурное или высокоуровневое проектирование).
2. Проектирование компонентов (проектирование

модулей, проектирование «в малом», детализированное или низкоуровневое проектирование).
В некоторых случаях выделяют связующий промежуточный подпроцесс:
3. Проектирование взаимодействия (проектирование управления, проектирование «в среднем», механистическое или среднеуровневое проектирование).

организации её компонентов.
Архитектура ПО – представление ПО как системы

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

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

такое определение оказывается слишком узким для этого классического процесса. Поэтому в настоящее время используется понятие «конструирование», определяемое следующим образом: Конструирование – процесс ЖЦ, который заключается в создании программного кода разрабатываемого ПО посредством комбинации дальнейшей детализации дизайна, кодирования и необходимого тестирования.
В результате этот процесс оказывается наиболее связанным со смежными процессами – проектированием и тестированием.

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

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

заключается в оценке и улучшении качества ПО. В общем случае

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

вида необходимо выполнять во время всего ЖЦ ПО. Большинство вопросов,

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

– процесс ЖЦ, который заключается в передаче разработанного ПО в

эксплуатацию.
Он включает следующие действия:
1. Распространение (доставка заказчику) продукта
2. Инсталляция (установка на конкретные системы) продукта.

заключается модификации ПО после ввода его в действие для улучшения

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

устранение сбоев и т.д.
Адаптивное сопровождение – модификация для учёта

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

– процесс ЖЦ, который заключается в прекращении сопровождения эксплуатируемого ПО.

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

ПО являются две методологии – структурная и объектно-ориентированная (OO). Принципиальное

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

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

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

Диаграммы потоков управления; Таблицы / деревья решений; Сети Петри; Диаграммы

функционального моделирования.
ОО методология: КОК-карты (CRC); Диаграммы прецедентов; Диаграммы классов и объектов; Диаграммы состояний; Диаграммы деятельности; Диаграммы последовательности.

проектирование.
ОО методология:
Проектирование предметных областей;
Проектирование наведением мостов.

связь» (ERD); Структурные карты; Скобочные диаграммы Варнье – Орра; Диаграммы

деятельности; Диаграммы переходов состояний (STD); Блок-схемы, структурные схемы; Псевдокод; Блок-схемы, потоковые схемы; Диаграммы Несси – Шнейдермана.
ОО методология: Диаграммы кооперации; Диаграммы компонентов; Диаграммы развёртывания.

ДеМарко (SAD); Подход Гейна – Сарсона (SSA); Подход Константайна (SSD);

Подход Джексона (JSD); Подход Варнье – Орра (DSSD); Подход Мартина (IE); Подход структурированного анализа и проектирования (SADT); Подход промышленной технологии DATARUN; Подход промышленного метода Oracle.
ОО методология: Подход на основе языка UML; Подход Гради Буча (Booch); Подход Джеймса Рамбо (OMT); Подход Айвара Якобсона (OOSE); Подход Шлеер – Меллора (RD).