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

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

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

5 Пятое требование состоит в том, что выбранные показатели качества должны постоянно измеряться и эти измерения должны протоколироваться.

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

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

Артефакты и роли

В понятие продукта разработки включается не только программный код  — сюда относятся различные артефакты, такие как планы, отчеты, диаграммы. Кроме того, участвующие в процессе разработчики играют разнообразные роли. В терминологии рассматриваемого далее Унифицированного процесса разработки программного обеспечения (USDP) эти роли называются работниками (workers). Используемая в USDP нотация для артефактов и работников приводится на рис. 1.6.

 

8. Архитектура программного обеспечения.  Выбор архитектуры. Классификация  архитектур.

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

Создание архитектуры — это проектирование на самом высоком уровне. Оставшуюся часть процесса проектирования мы будем называть детальным проектированием.

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

Цели выбора архитектуры

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

1. Расширение.

Облегчение добавления новых  свойств.

2. Изменения.

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

3. Простота:

• простота понимания;
• простота реализации.

4. Эффективность:

• достижение высокой скорости: выполнения и (или) компиляции;
• достижение малого размера: объектного кода и (или) исходного кода.

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

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

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

Классификация архитектур

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

1. Архитектуры потоков данных.

• Последовательные пакеты.
• Каналы и фильтры.

2. Независимые компоненты.

• Параллельные взаимодействующие процессы.
• Клиент-серверные системы.
• Системы, управляемые событиями.

3. Виртуальные машины.

• Интерпретаторы.
• Системы, основанные на правилах.

4. Репозиторные архитектуры.

• Базы данных.
• Гипертекстовые системы.
• Доски объявлений.

5. Уровневые архитектуры.

9. Жизненный цикл ПО. Разновидности процесса разработки.

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента  принятия решения о необходимости  создания программного продукта и заканчивается  в момент его полного изъятия  из эксплуатации. Этот цикл — процесс  построения и развития ПО.

Модели жизненного цикла  ПО:

Водопадная (каскадная, последовательная) модель

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

Этапы проекта в соответствии с каскадной моделью:

Формирование требований;

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

Реализация;

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

Внедрение;

Эксплуатация и сопровождение.

Преимущества:

Полная и согласованная  документация на каждом этапе;

Легко определить сроки и  затраты на проект.

Недостатки:

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

Итерационная модель

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной  разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью[4].

Модель IID предполагает разбиение  жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение  работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат  финальной итерации содержит всю  требуемую функциональность продукта. Таким образом, с завершением  каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются  эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения[3].

По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»[4].

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень  долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать  часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет  переделать и улучшить позже»[3].

Различные варианты итерационного  подхода реализованы в большинстве  современных методологий разработки (RUP, MSF, XP).

Спиральная модель

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

риск превышения сроков и  стоимости проекта;

необходимость выполнения ещё  одной итерации;

степень полноты и точности понимания требований к системе;

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

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

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

Дефицит специалистов.

Нереалистичные сроки  и бюджет.

Реализация несоответствующей  функциональности.

Разработка неправильного  пользовательского интерфейса.

Перфекционизм, ненужная оптимизация и оттачивание деталей.

Непрекращающийся поток  изменений.

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

Недостатки в работах, выполняемых внешними (по отношению  к проекту) ресурсами.

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

Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий  набор контрольных точек:

Concept of Operations (COO) — концепция (использования) системы;