Традиционно инженеры стремились, а некоторые из них, не снижая качества проектов, добивались значительного сокращения сроков проектирования. В начале Великой Отечественной войны начальник Центрального артиллерийского конструкторского бюро В.Г. Грабин разработал и применил методы скоростного комплексного проектирования артиллерийских систем с одновременным проектированием технологического процесса. Внедрение этого метода позволило сократить сроки проектирования, производства и испытаний артиллерийских орудий с 30 мес (1939) до 2–2,5 мес (1943), увеличить их выпуск, уменьшить стоимость, упростить эксплуатацию.

Инженерный технологический подход [20] определяется спецификой комбинации стадий разработки, этапов и видов работ, ориентированной на разные классы программного обеспечения и особенности коллектива разработчиков.

Основные группы инженерных технологических подходов и подходы для каждой из них следующие:

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

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

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

Классификация технологических подходов к созданию программ:

Подходы со слабой формализацией

Подход "кодирование и исправление"

Строгие подходы

Каскадные технологические подходы:

— классический каскадный;

— каскадно-возвратный;

— каскадно-итерационный;

— каскадный подход с перекрывающимися видами работ;

— каскадный подход с подвидами работ;

— спиральная модель.

Каркасные технологические подходы:

— рациональный унифицированный подход к видам работ.

Генетические технологические подходы:

— синтезирующее программирование;

— сборочное (расширяемое) программирование;

— конкретизирующее программирование.

Подходы на основе формальных преобразований:

— технология стерильного цеха;

— формальные генетические подходы.

Гибкие подходы

Ранние подходы быстрой разработки:

— эволюционное прототипирование;

— итеративная разработка;

— постадийная разработка.

Адаптивные технологические подходы:

— экстремальное программирование;

— адаптивная разработка;

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

— компьютерный дарвинизм.

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

Подход "кодирование и исправление" (code and fix) упрощенно может быть описан следующим образом. Разработчик начинает кодирование системы с самого первого дня, не занимаясь сколь-либо серьезным проектированием. Все ошибки обнаруживаются, как правило, к концу кодирования и требуют исправления через повторное кодирование.

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

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

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

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

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

Классический каскадный подход (от англ. pure waterfall — чистый водопад) считается "дедушкой" технологических подходов к ведению жизненного цикла. Его можно рассматривать как отправную точку для огромного количества других подходов. Сформировался классический каскадный подход в период с 1970 по 1985 г. Специфика "чистого" каскадного подхода такова, что переход к следующему виду работ осуществляется только после того, как завершена работа с текущим видом работы (рис. 3.1). Возвраты к уже пройденным видам работ не предусмотрены.

Рис. 3.1. Классический каскадный подход

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

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

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

Каскадный подход с перекрывающимися видами работ (англ. waterfall with overlapping), так же как и классический каскадный подход предполагает проведение работ отдельными группами разработчиков, но эти группы не меняют специализацию от разработки к разработке, что позволяет распараллелить работы и в определенной степени сократить объем передаваемой документации (рис. 3.4).

Рис. 3.2. Каскадно-возвратный технологический подход

Рис. 3.3. Каскадно-итерационный технологический подход

Рис. 3.4. Каскадный подход с перекрывающимися видами работ

Каскадный подход с подвидами работ (англ. waterfall with subprocesses) очень близок подходу с перекрывающимися видами работ. Особенность его в том, что с точки зрения структуры, проект достаточно часто может быть разделен на подпроекты, которые могут разрабатываться индивидуально (рис. 3.5). В данном подходе требуется дополнительная фаза тестирования подсистем до объединения их в единую систему. Следует особое внимание обращать на грамотное деление проекта на подпроекты, которое должно учесть все возможные зависимости между подсистемами.

Рис. 3.5. Каскадный подход с подвидами работ

Рис. 3.6. Спиральная модель

Спиральная модель (spiral model) была предложена Барри Боэмом (Barry Boehm) в середине 80-х годов XX в. с целью сократить возможный риск разработки. Фактически, это была первая реакция на устаревание каскадной модели. Спиральная модель использует понятие прототипа — программы, реализующей частичную функциональность создаваемого программного продукта. Создание прототипов осуществляется в несколько витков спирали, каждый из которых состоит из "анализа риска", "некоторого вида работ" и "верификации" (рис. 3.6). Обращение к каждому виду работы предваряет "анализ риска", причем если риск превышения сроков и стоимости проекта оказывается существенным, то разработка заканчивается. Это позволяет предотвратить более крупные денежные потери в будущем.

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

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

Рациональный унифицированный подход к выполнению работ

(rational unified process-RUP), изложенный подробно в десятой главе данного учебника, вобрал в себя лучшее из технологических подходов каскадной группы. Весомое преимущество данного подхода состоит в созданном инструментарии его автоматизированной поддержки — программного продукта Rational Rose фирмы "Rational Software Corpation".

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

Основные особенности данного подхода:

• итеративность с присущей ей гибкостью;

• контроль качества с возможностью выявления и устранения рисков на самых ранних этапах;

• предпочтение отдается моделям, а не бумажным документам;

• основное внимание уделяется раннему определению архитектуры;

• возможность конфигурирования, настройки и масштабирования.

Рис. 3.7. Рациональный унифицированный подход к видам работ

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

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

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

— выбрать язык реализации и аппаратно-программную платформу для реализации;

— зафиксировать отображение понятий языка спецификаций на язык реализации и аппаратно-программную платформу;

— осуществить трансформацию представления (из спецификации в исполняемую программу на языке реализации);

— отладить и протестировать исполняемую программу.

Автоматическая генерация программ по спецификациям возможна для многих языков спецификаций, особенно для SDL, ASN.1, LOTOS, Estelle, UML (Rational Rose).

Сборочное (расширяемое) программирование предполагает, что программа собирается путем повторного использования уже известных фрагментов (рис. 3.8).

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

— выработка стиля программирования, соответствующего принятым принципам модульности;

— повышение эффективности межмодульных интерфейсов; важность аппаратной поддержки модульности;

— ведение большой базы программных модулей; решение проблемы идентификации модулей и проверки пригодности по описанию интерфейса. (Модули должны стать "программными кирпичиками", из которых строится программа.)

Рис. 3.8. Сборочное программирование

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

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

2. Объектно-ориентированное сборочное программирование базируется на методологии объектно-ориентированного программирования и предполагает распространение библиотек классов в виде исходного кода или упаковку классов в динамически компонуемую библиотеку.

3. Компонентное сборочное программирование предусматривает распространение классов в бинарном виде и предоставление доступа к методам класса через строго определенные интерфейсы, что позволяет снять проблему несовместимости компиляторов и обеспечивает смену версий классов без перекомпиляции использующих их приложений. Существуют конкретные технологические подходы, поддерживающие компонентное сборочное программирование — COM (DCOM, COM+), CORBA, Net. (см. 6.6).

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

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

Наиболее известная технология конкретизирующего программирования — это подход с применением паттернов проектирования (см. 8.6).

Дополнительно к паттернам существуют каркасы (framework) — наборы взаимодействующих классов, составляющих повторно используемый дизайн для конкретного класса программ. Каркас диктует определенную архитектуру приложения, в нем аккумулированы проектные решения, общие для проектной области. Например, существуют каркасы, которые используются для разработки компиляторов.

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

Технология стерильного цеха. Основные идеи технологии стерильного цеха (cleanroom process model) были предложены Харланом Миллзом в середине 80-х годов XX в. Технология складывается из следующих частей (рис. 3.9):

• разработка функциональных и пользовательских спецификаций;

• инкрементальное планирование разработки;

• формальная верификация;

• статистическое тестирование.

Процесс проектировании связан с представлением программы как функции в виде так называемых "ящиков":

• черного ящика с фиксированными аргументами (стимулами) и результатами (ответами);

• ящика с состоянием, в котором выделяется внутреннее состояние;

• прозрачного (белого) ящика, представляющего реализацию в виде совокупности функций при пошаговом уточнении.

Использование ящиков определяют следующие три принципа:

— все определенные при проектировании данные скрыты (инкапсулированы) в ящиках;

— все виды работ определены как использующие ящики последовательно или параллельно;

— каждый ящик занимает определенное место в системной иерархии.

Рис. 3.9. Технология стерильного цеха

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

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

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

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

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

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

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

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

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

• итерационную разработку прототипа;

• тесное взаимодействие с заказчиком.

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

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

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

Итеративная разработка. Первый прототип итеративной разработки (iterative delivery) уже должен включать завершенное ядро системы. Таким образом, в нем уже сосредоточена большая часть функциональности. Очередные итерации должны помочь пользователю определиться с доводкой пользовательского интерфейса и генерируемых систем отчетов и других выходных данных (рис. 3.11).

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

Рис. 3.10. Эволюционное прототипирование

Рис. 3.11. Итеративная разработка

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

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

Адаптивные технологические подходы были задуманы как подходы, поддерживающие изменения. Они только выигрывают от изменений, даже когда изменения происходят в них самих. Данные подходы ориентированы на человека, а не на процесс. Во время работы в них необходимо учитывать природные качества человеческой натуры, а не действовать им наперекор (http://www.martinfowler.com).

Экстремальное программирование. Наиболее концентрированно идеи быстрой разработки программ оказались выражены в подходе экстремального программирования (extreme programming) (XP) (http://www.extremeprogramming.org). Две основные черты, присущие быстрым разработкам, являются базовыми и в этом подходе. Методы, объединенные в данном подходе, не являются принципиально новыми. Однако именно их рациональное объединение и совокупное использование дают существенные результаты и успешно выполненные проекты. Наибольшую пользу подход экстремального программирования может принести в разработке небольших систем, требования к которым четко не определены и позднее могут измениться.

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

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

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

— этап планирования реализации: заказчики пишут сценарии работы системы на основе списка историй — возможных применений системы, программисты адаптируют их к разработке, после чего заказчики выбирают первоочередной из написанных сценариев;

— итерационный этап: заказчики пишут тесты и отвечают на вопросы разработчиков, пока последние программируют;

— этап выпуска версии: разработчики устанавливают систему, заказчики принимают работу.

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

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

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

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

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

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

Рис. 3.12. Работа над проектом на основе экстремального программирования

Одним из существенных методов данного подхода является функциональное тестирование. Существуют две особенности процесса тестирования:

• программисты сами пишут тесты для тестирования программы;

• эти тесты пишутся до начала кодирования.

Для любого автономного модуля (класса, процедуры, Unit-модуля) программисты пишут отдельный модульный тест, который должен тестировать все основные варианты использования этого модуля и храниться вместе с ним. Результаты прогонов тестов должны быть лаконичными, например "ОК! (10 tests)". Главное — тест должен писаться до написания самого модуля! Такое тестирование называют опережающим. Внесение изменений на каждой итерации проекта (рефакторинг) всегда сопровождается прогоном всех тестов, чтобы гарантировать стабильную работу системы. Уверенность в нормальной работе как каждого отдельного теста, так и всех тестов комплексного теста придает разработчикам уверенность в нормальной работе очередной версии системы на каждой итерации проекта.

Цель каждой итерации (рис. 3.13) — включить в версию несколько новых историй. На собрании по планированию итерации определяется, какие именно истории и каким образом будут они реализованы командой разработчиков.

Коллективное владение кодом в процессе разработки (рис. 3.14) означает возможность для каждого программиста в любое время усовершенствовать любую часть кода в системе, если он сочтет это необходимым. Программист берет на себя ответственность за реализацию определенных задач. В случае возникновения вопросов по разрабатываемой задаче может быть проведено короткое (15-минутное) собрание в присутствии заказчика.

Рис. 3.13. Работа на итерации экстремального программирования

Рис. 3.14. Коллективное владение кодом при экстремальном программировании

Чтобы выполнить задачу, ответственный за нее программист должен найти себе партнера (рис. 3.15). Окончательный код всегда пишется двумя программистами на одной рабочей станции.

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

Адаптивная разработка. В основу подхода адаптивной разработки (Adaptive Software Development — ASD) положены три нелинейных перекрывающих друг друга этапа — обдумывание, сотрудничество и обучение. Автор данного подхода Джим Хайсмит (Jim Highsmith) обращает особое внимание на использование идей из области сложных адаптивных систем.

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

Рис. 3.15. Работа над кодом парой программистов при экстремальном программировании

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

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

Исследовательское программирование имеет следующие особенности (http://www.osp.ru/pcworld/2001/01/062.htm):

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

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

— разработка не поддается детальному планированию, она ведется методом проб и ошибок;

— работа связана с конкретными исполнителями и отражает их личностные качества.

В основе исследовательского программирования в большей степени, чем в других подходах, лежит искусство.

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

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

Подход состоит из трех основных видов работ:

• макетирование (прототипирование);

• тестирование;

• отладка.

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

ВЫВОДЫ

• Традиционно инженеры стремились, а некоторые из них добивались не снижая качества проектов, значительного сокращения сроков проектирования.

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

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

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

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

• Каркасные подходы представляют собой каркас для видов работ. Одним из ярких представителей каркасного подхода является рациональный унифицированный подход к выполнению работ, поддерживаемый САПР на основе программного продукта Rational Rose фирмы "Rational Software Corporation".

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

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

• Выбор оптимального инженерного технологического подхода обеспечивает сокращение сроков выполнения проекта без снижения качества проекта.

Контрольные вопросы

1. За счет чего инженеры добиваются резкого сокращения сроков выполнения проектов?

2. Какие известны основные группы инженерных технологических подходов?

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

4. Какие инженерные технологические подходы были развиты в последнее время?

5. В чем состоят преимущества и недостатки каскадно-возвратного подхода по сравнению с классическим каскадным подходом?

6. Какой вид работ отсутствует в технологии стерильного цеха?

7. В каких случаях разумно применять эволюционное прототипирование?

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

9. В чем состоит суть адаптивной разработки?