Глухова Л.А. Технологии разработки программного обеспечения

Подождите немного. Документ загружается.

№ п/п

Критерии категории

команды разработчиков

проекта

Каскад

ная

V-

образ-

ная

RAD

Инкре-

мент-

ная

Эволю

цион-

ная

Спира-

льная

гибкость?

7 Будет ли руководитель

проекта отслеживать

прогресс команды

разработчиков в ходе

проекта?

Да Да Нет Да Нет Да

8 Важна ли легкость

распределения ресурсов

проекта?

Да Да Да Да Нет Нет

9 Приемлет ли команда

разработчиков оценки,

проверки, стадии

разработки?

Да Да Нет Да Да Да

Таблица 3.3 – Выбор модели жизненного цикла на основе характеристик

коллектива пользователей

№ п/п

Критерии категории

коллектива пользователей

Каскад

ная

V-

образ-

ная

RAD

Инкре-

мент-

ная

Эволю

цион-

ная

Спира-

льная

1 Будет ли присутствие

пользователей ограничено

в жизненном цикле

разработки?

Да Да Нет Да Нет Да

2 Будут ли пользователи

знакомиться с

определением системы в

жизненном цикле

разработки?

Нет Нет Нет Да Да Да

3 Будут ли пользователи

знакомиться с проблемами

предметной области в

жизненном цикле

разработки?

Нет Нет Да Да Да Нет

4 Будут ли пользователи

вовлечены в большинство

фазы жизненного цикла

Нет Нет Да Нет Да Нет

№ п/п

Критерии категории

коллектива пользователей

Каскад

ная

V-

образ-

ная

RAD

Инкре-

мент-

ная

Эволю

цион-

ная

Спира-

льная

разработки?

5 Будет ли заказчик

отслеживать ход

выполнения проекта?

Нет Нет Нет Нет Да Да

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

проектов и рисков

№

п/п

Критерии категории типов

проекта и рисков

Каска-

дная

V-

образ-

ная

RAD

Инкре-

мент-

ная

Эволю

-цион-

ная

Спи-

раль-

ная

1 Будет ли проект

идентифицировать новое

направление продукта для

организации?

Нет Нет Нет Да Да Да

2 Будет ли проект иметь тип

системной интеграции?

Нет Да Да Да Да Да

3 Будет ли проект являться

расширением

существующей системы?

Нет Да Да Да Нет Нет

4 Будет ли проект крупно-

или среднемасштабным?

Нет Нет Нет Да Да Да

5 Будет ли финансирование

проекта стабильным на

всем протяжении

жизненного цикла?

Да Да Да Нет Да Нет

6 Будет ли продукт проекта

критичным?

Нет Нет Нет Нет Да Да

7 Ожидается ли длительная

эксплуатация продукта в

организации?

Да Да Нет Да Нет Да

8 Необходим ли высокий

уровень надежности

продукта проекта?

Нет Да Нет Да Нет Да

№

п/п

Критерии категории типов

проекта и рисков

Каска-

дная

V-

образ-

ная

RAD

Инкре-

мент-

ная

Эволю

-цион-

ная

Спи-

раль-

ная

9 Предполагается ли

эволюция продукта проекта

в течение жизненного

цикла?

Нет Нет Нет Да Да Да

10 Будет ли система

изменяться на этапе

сопровождения?

Нет Нет Нет Да Да Да

11 Является ли график

сжатым?

Нет Нет Да Да Да Да

12 Являются ли известными

интерфейсные модули?

Да Да Нет Да Нет Нет

13 Предполагается ли

повторное использование

компонентов?

Нет Нет Да Да Да Да

14 Являются ли достаточными

ресурсы (время, деньги,

инструменты, персонал)?

Нет Нет Нет Нет Да Да

3.3. Адаптация модели жизненного цикла

разработки ПС и систем к условиям

конкретного проекта

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

и систем является международный стандарт ISO/IEC 12207:1995 и аутентичный

стандарт Республики Беларусь СТБ ИСО/МЭК 12207-2003 [1, 8].

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

должен осуществляться при выполнении первой работы (подготовка процесса

разработки) процесса разработки (см. подразд. 1.2). В стандарте определено,

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

договоре, то разработчик должен определить или выбрать модель жизненного

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

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

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

применения модели в конкретном проекте.

Вторая стадия заключается в адаптации выбранной модели к

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

организации, и к требованиям действующих стандартов.

С учетом этого должны быть выбраны и структурированы в модель

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

из стандарта СТБ ИСО/МЭК 12207-2003. Данные работы и задачи могут

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

рекурсивно.

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

данную модель работ и задач процесса разработки из стандарта СТБ ИСО/МЭК

12207-2003 влияют основные характеристики проекта. Данные характеристики

определены в стандартах СТБ ИСО/МЭК 12207-2003 и ГОСТ Р ИСО/МЭК ТО

15271–2002 [8, 6]. В соответствии с данными стандартами к основным

характеристикам проекта относятся:

1) организационные подходы (например, связанные с защитой,

безопасностью, конфиденциальностью, управлением риском, использованием

независимого органа по верификации и аттестации, использованием

конкретного языка программирования, обеспечением техническими

ресурсами);

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

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

сопровождения и периодичность внесения изменений, критичность

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

сопровождения среда);

4) вовлеченные стороны (например, заказчик, поставщик, разработчик,

субподрядчик, посредники по верификации и аттестации, персонал

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

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

заказчиком, разработка и сопровождение поставщиком);

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

и объектов конфигурации, межсистемные и внутрисистемные интерфейсы,

интерфейсы пользователя, влияние ошибок ПС на защиту и безопасность

системы, оценка временных мощностей и временных ограничений, наличие

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

компьютеров);

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

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

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

средств по ISO/IEC 9126–1:2001 [3]); выделяются следующие типы

программных продуктов:

· новая разработка; должны учитываться все требования к

процессу разработки;

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

выполнена оценка функциональных характеристик,

документации, применимости, возможность поддержки; процесс

разработки может не понадобиться;

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

выполнена оценка функциональных характеристик,

документации, применимости, возможность поддержки; процесс

разработки реализуется с учетом критичности продукта и

величины изменений;

· программный или программно-аппаратный продукт, встроенный

или подключенный к системе; необходимо учитывать работы

процесса разработки, связанные с системой;

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

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

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

ИСО/МЭК 12207 можно не учитывать;

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

или сотни лиц, необходим тщательный административный надзор и контроль с

применением процессов совместного анализа, аудита, верификации,

аттестации, обеспечения качества; для малых проектов такие методы контроля

могут быть излишними);

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

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

для таких ПС необходим более тщательный надзор и контроль);

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

ПС, которое трудно сопровождать и использовать, неправильное, неточное или

неполное определение требований).

11) другие характеристики (например, усиленный административный

контроль за критичными или большими программными продуктами).

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

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

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

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

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

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

позиции как в качестве классической технологии, так и в качестве основы для

современных технологий разработки ПС.

Под модуляцией (модуляризацией) понимается разделение программы на

части по некоторым установленным правилам [12]. Для различных языков

программирования это могут быть внутренние подпрограммы, внешние модули

и т.п.

Классическое определение идеальной модульной программы выглядит

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

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

частях программы.

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

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

2) Независимость модулей. Это значит, что модуль можно изменять или

модифицировать без последствий в других модулях.

3) Условие «один вход – один выход». Модульная программа должна

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

случае может быть и более чем один вход, но важно, чтобы точки входов были

строго определены и другие модули не могли входить в данный модуль в

произвольной точке.

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

проектирования:

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

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

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

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

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

Недостатки модульности:

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

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

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

центрального процессора (в среднем на 5 - 10%) за счет времени обращения к

модулям.

3) Модульность программы приводит к увеличению объема программ (в

среднем на 5 - 10%).

Методы проектирования модульных программ делятся на 3 группы:

1) Методы нисходящего проектирования.

2) Методы расширения ядра.

3) Методы восходящего проектирования.

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

4.2. Метод нисходящего проектирования

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

разбиения большой задачи на меньшие подзадачи так, чтобы каждую задачу

можно было рассматривать независимо.

Суть метода заключается в следующем.

На начальном шаге в соответствии с назначением всей программы

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

частей.

Затем определяются подфункции программы и в соответствии с ними

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

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

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

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

прозрачны, что их можно непосредственно программировать, принимается

решение о прекращении дальнейшего проектирования.

Таким образом, на каждом шаге разработки уточняется реализация

фрагмента алгоритма, то есть решается более простая задача.

Следует отметить, что метод нисходящего проектирования положен в

основу стандартного процесса разработки, регламентированного стандартом

СТБ ИСО/МЭК 12207-2003 [8].

Метод нисходящего проектирования основан на двух стратегиях [12]:

1) пошаговое уточнение (данная стратегия разработана Е. Дейкстрой)

2) анализ сообщений (данная стратегия базируется на работах группы

авторов: Йодана, Константайна, Мейерса).

Эти стратегии отличаются способами определения начальных

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

записи (нотациями), положенными в основу проектирования.

4.2.1. Пошаговое уточнение

Пошаговое уточнение является одной из стратегий, реализующих метод

нисходящего проектирования.

При пошаговом уточнении на каждом следующем этапе декомпозиции

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

При этом результаты каждого этапа являются уточнением результатов

предыдущего этапа лишь с небольшими изменениями.

Существуют различные способы реализации пошагового уточнения. В

данном учебном пособии рассмотрены два из них:

1)кодирование программы с помощью псевдокода и управляющих

конструкций структурного программирования;

2)использование комментариев для описания обработки данных.

Пошаговое уточнение требует, чтобы взаимное расположение строк

программы обеспечивало читабельность всей программы.

Общее правило записи текста разрабатываемой программы: служебные

слова, которыми начинается и заканчивается та или иная управляющая

конструкция, записываются на одной вертикали; все вложенные в данную

конструкцию псевдокоды (или комментарии или операторы) и управляющие

конструкции записываются с отступом вправо.

Преимущества метода пошагового уточнения:

1) Основное внимание при его использовании обращается на

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

2) Так как каждый последующий этап является уточнением предыдущего

лишь с небольшими изменениями, то легко может быть выполнена проверка

корректности процесса разработки на всех этапах.

Недостаток метода пошагового уточнения: на поздних этапах

проектирования может обнаружиться необходимость в структурных

изменениях, требующих пересмотра более ранних решений.

4.2.2. Кодирование программы с помощью

псевдокода и управляющих конструкций

структурного программирования

Одним из способов реализации пошагового уточнения является

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

структурного программирования.

При использовании данного способа разбиение программы на модули

осуществляется эвристическим способом. На каждом этапе проектирования по

возможности не уточняются операции с данными (это откладывается на

возможно более поздние сроки). Но выбор необходимых управляющих

конструкций осуществляется на каждом этапе [12].

Таким образом, фактически проектируется управляющая структура

программы.

На этапе, когда принимается решение о прекращении дальнейшего

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

вызываемыми модулями (или подпрограммами), а проектируемый модуль –

управляющим модулем.

Пример 4.1.

Рассмотрим пример проектирования некоторой абстрактной программы.

Пусть программа обрабатывает пакеты некоторых групп записей [12]. Пакет

состоит из групп записей, каждая группа сопровождается управляющей

записью, имеет заголовок и окончание.

Первый этап пошагового уточнения.

Задается заголовок программы, соответствующий ее основной функции.

Рrogram Обработка_пакетов.

Второй этап пошагового уточнения.

Определяются основные шаги обработки пакетов информации.

Program Обработка_пакетов;

Сортировать_группы_по_управляющим_записям

Отделить_группы_с_правильными_управляющими_записями_от_

групп_с_неправильными_управляющими_записями_и_обработать {*}

EndРrogram.

Фрагмент программы, детализированный на втором этапе, располагается

правее детализированного на первом этапе.

Третий этап пошагового уточнения.

Дальнейшая детализация программы. Детализация фрагмента *.

Возможно появление необходимости в использовании управляющих

конструкций структурного программирования.

Program Обработка_пакетов;

Сортировать_группы_по_управляющим_записям

Взять_первую_группу

While не_конец_входного_файла Do

Взять_правильную_управляющую_запись

Обработать_группу_записей

End

Обработать_группы_с_неправильной_управляющей_записью

EndРrogram.

На некоторых этапах уточнения можно приостановить определение

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

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

обработки или если необходимо отложить их детализацию (например, в

примере это может быть подфункция «Обработать_неправильные_

управляющие_группы»).

Процесс детализации продолжается, пока не будет принято решение о

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

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

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

использованием принципа структурного программирования.

4.2.3. Использование комментариев

для описания обработки данных

Вторым из рассматриваемых способов реализации пошагового уточнения

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

При этом способе на каждом этапе уточнений используются управляющие

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

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

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

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

В результате после окончания проектирования получается хорошо

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

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

1) Заголовки. Объясняют назначение основных блоков программы на

отдельных этапах пошаговой детализации.

2) Построчные. Описывают мелкие фрагменты программы.

3) Вводные. Помещаются в начале текста программы и задают общую

информацию о программе (назначение программы, сведения об авторах, дата

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

памяти).

Считается, что один из самых больших недостатков программы –

отсутствие в ней комментариев. В среднем нужно руководствоваться

следующими нормами комментариев:

· 4 - 5 строк комментария-заголовка на каждую подпрограмму или блок;

· по одному комментарию на каждые 2 - 3 строки исходного текста для

построчных комментариев.

Пример 4.2.

Рассмотрим тот же пример проектирования некоторой абстрактной

программы, который был рассмотрен в примере 4.1. Пусть программа