№	Критерии категории типов	Каска-	V-			Инкре-	Эволю	Спи-
			образ-		RAD	мент-	-цион-	раль-
п/п	проекта и рисков	дная	ная			ная	ная		ная
9	Предполагается ли
	эволюция продукта проекта	Нет	Нет			НетДа	Да		Да
	в течение жизненного
	цикла?
10	Будет ли система	Нет	Нет			НетДа	Да		Да
	изменяться на этапе
	сопровождения?
11	Является ли график	Нет	Нет Да			Да	Да		Да
	сжатым?
12	Являются ли известными	Да	Да		Нет	Да	Нет				Нет
	интерфейсные модули?
13	Предполагается ли
	повторное использование	Нет	Нет Да			Да	Да		Да
	компонентов?
14	Являются ли достаточными
	ресурсы (время, деньги,	Нет	Нет			Нет	Нет				Да
	инструменты, персонал)?

3.3.Адаптация модели жизненного цикла разработки ПС и систем к условиям конкретного проекта

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

исистем является международный стандарт ISO/IEC 12207:1995 и аутентичный стандарт Республики Беларусь СТБ ИСО/МЭК 12207-2003 [1, 8].

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

исложности проекта.

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

63

организации, и к требованиям действующих стандартов.
С учетом этого должны быть выбраны и структурированы в модель
жизненного цикла программных средств работы и задачи процесса разработки
из стандарта СТБ		ИСО/МЭК 12207-2003.			Данные		работы и	задачи	могут
пересекаться	или	взаимодействовать			и	выполняться		итерационно		и
рекурсивно.
На вопросы выбора модели жизненного цикла и структурирования в
данную модель работ и задач процесса разработки из стандартаСТБ ИСО/МЭК
12207-2003 влияют основные характеристики проекта. Данные характеристики
определены в стандартах СТБ ИСО/МЭК 12207-2003 и ГОСТ Р ИСО/МЭК ТО
15271–2002 [8,	6]. В соответствии с данными стандартамиосновнымк
характеристикам проекта относятся:
1) организационные			подходы (например,			связанные		с	защитой,
безопасностью, конфиденциальностью, управлением риском, использованием
независимого	органа		по	верификации		и	аттестации, использованием
конкретного	языка		программирования, обеспечением					техническими
ресурсами);

2)политика заказа (например, типы договора);

3)политика сопровождения ПС(например, ожидаемые период

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

сопровождения среда);
4) вовлеченные стороны (например, заказчик,			поставщик, разработчик,
субподрядчик, посредники	по	верификации	и	аттестации, персонал

сопровождения; численность сторон);

5)работы жизненного цикла системы(например, подготовка проекта заказчиком, разработка и сопровождение поставщиком);

6)характеристики системного уровня (например, количество подсистем

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

7)характеристики программного уровня(например, количество программных объектов, типы, объемы и критичность программных продуктов, технические риски, типы документов, характеристики качества программных

средств	по ISO/IEC		9126–1:2001 [3]);		выделяются	следующие типы
программных продуктов:
	·	новая	разработка;	должны	учитываться	все	требования к
		процессу разработки;
	·	использование готового программного продукта; должна быть
		выполнена		оценка	функциональных		характери,
		документации, применимости, возможность поддержки; процесс
		разработки может не понадобиться;

64

· модификация готового программного продукта; должна быть

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

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

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

·непоставляемый программный продукт; требования стандарта ИСО/МЭК 12207 можно не учитывать;

8)объем проекта (в больших проектах, в которые вовлечены десятки или сотни лиц, необходим тщательный административный надзор и контроль с

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

9)критичность проекта (значительная зависимость работы системы от

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

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

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

65

РАЗДЕЛ 4. КЛАССИЧЕСКИЕ

ТЕХНОЛОГИИ РАЗРАБОТКИ

ПРОГРАММНЫХ СРЕДСТВ

4.1. Модульное проектирование программ

Модульное	проектирование	программ	является	одной	из	первы
технологий разработки ПС и		уже несколько	десятилетий сохраняет			свои

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

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

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

Признаки модульности программы:

1)Программа состоит из модулей.

2)Независимость модулей. Это значит, что модуль можно изменять или модифицировать без последствий в других модулях.

3)Условие «один вход – один выход». Модульная программа должна состоять из модулей, имеющих одну точку входа и одну точку выхода. В общем случае может быть и более чем один вход, но важно, чтобы точки входов были строго определены и другие модули не могли входить в данный модуль в произвольной точке.

Достоинства	(а	следовательно,	и	назначение)	модульного
проектирования:

1)Упрощение разработки и реализации программ.

2)Облегчение чтения программ.

3)Упрощения настройки и модификации программ.

4)Облегчение работы с данными, имеющими сложную структуру.

5)Исключение чрезмерной детализации алгоритмов. Недостатки модульности:

1)Модульность требует большей дополнительной работы программиста

иопределенных навыков проектирования программ.

66