Материал: Лекция_2_СС

6

средств, выбор и установка аппаратных и программных средств.

Процесс усовершенствования - оценка, контроль и усовершенствование процессов ЖЦ ПО.

Процесс обучения - первоначальное обучение и последующее постоянное повышение квалификации персонала.

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

19.102-77 «Стадии разработки»):

•постановка задачи (стадия «Техническое задание»);

•анализ требований и разработка спецификаций (стадия «Эскизный проект»);

•проектирование (стадия «Технический проект»);

•реализация (стадия «Рабочий проект»).

Традиционно разработка также включала этап сопровождения (началу этого этапа соответствует стадия «Внедрение» по ГОСТ). Но по международному стандарту в соответствии с изменениями,

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

Условность выделения этапов связана с тем, что на любом этапе возможно принятие решений,

которые потребуют пересмотра решений, принятых ранее.

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

определяющие особенности его функционирования.

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

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

Анализ требований и определение спецификаций. Спецификация - точное формализованное описание функций и ограничений разрабатываемого ПО. Различают функциональные и эксплуатационные спецификации. Совокупность спецификаций представляет собой общую логическую модель проектируемого ПО.

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

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

7

ПО. Процесс проектирования сложного ПО включает:

•проектирование общей структуры – определение основных компонентов и их взаимосвязей;

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

•проектирование компонентов.

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

Различают также два аспекта проектирования:

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

•физическое проектирование – привязка к конкретным техническим и программным средствам среды функционирования, т.е. учет ограничений, определенных в спецификациях.

Реализация - процесс поэтапного написания кодов программы на выбранном языке программирования (кодирование), их тестирование и отладку.

Сопровождение – это процесс создания и внедрения новых версий программного продукта.

Причинами выпуска новых версий могут служить:

•необходимость исправления выявленных ошибок;

•необходимость совершенствования предыдущих версий: улучшения интерфейса,

расширения состава выполняемых функций и пр.;

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

На этом этапе в программный продукт вносят необходимые изменения, которые также могут потребовать пересмотра проектных решений, принятых на любом предыдущем этапе. С изменением модели ЖЦ ПО (см. далее) роль этого этапа возросла, так как продукты теперь создаются итерационно:

сначала выпускается сравнительно простая версия, затем следующая с большими возможностями, затем следующая и т.д. Это и послужило причиной выделения этапа сопровождения в отдельный процесс ЖЦ в соответствии с стандартом ISO/IEC 12207.

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

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

Международный стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО.

8

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

Модель ЖЦ конкретного ПО определяет характер процесса его создания - совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям.

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

документации).

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

Каскадная модель (1970-1985). Первоначально была предложена и использовалась каскадная схема разработки ПО (рис.2), которая предполагала, что переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и

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

Формирование

требований

Проектирование

Реализация

Тестирование

Ввод в действие

Рис.2. Каскадная модель Каждая стадия завершается выпуском комплекта документации, достаточной для того, чтобы

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

Преимущества применения каскадной схемы:

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

простота планирования процесса разработки.

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

9

причинами:

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

изменение требований заказчика непосредственно в процессе разработки;

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

анализа и проектирования.

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

Модель с промежуточным контролем. Схема, поддерживающая итерационный характер процесса разработки, была названа схемой с промежуточным контролем (рис. 3). Контроль, который выполняется по данной схеме после завершения каждого этапа, позволяет при необходимости вернуться на любой уровень и внести необходимые изменения. Межстадийные корректировки обеспечивают большую надежность, хотя увеличивают весь период разработки.

Формирование

требований

Проектирование

Реализация

Тестирование

Ввод в действие

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

завершена, постоянно находясь в состоянии уточнения и усовершенствования.

Недостаток каскадной модели - существенное запаздывание с получением результатов и, как следствие, высокий риск создания системы, не удовлетворяющей и изменившимся потребностям пользователей. Это объяснятся причинами:

пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть,

как они изменятся в ходе разработки;

за время разработки могут произойти изменения во внешней среде, которые повлияют на

10

требования к системе.

Спиральная модель (1986-1990). Для преодоления перечисленных проблем в середине 80-х

годов была предложена спиральная модель ЖЦ (рис.4). Ее особенность: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования.

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

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

Рис. 4. Спиральная модель Спиральная модель избавляет пользователей и разработчиков от необходимости точного и

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

в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Основное достоинство спиральной модели – с некоторой итерации, на которой обеспечена