Файл: Основы проектирования программ. Этапы создания программного обеспечения (Каскадный цикл).pdf

Введение

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

Что же производят программисты? Программисты производят программный продукт. В терминах автоматизированных систем программисты создают программное обеспечение.

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

Следующий пример показывает нелинейную зависимость роста сложности задачи от ее размера. Необходимо в уме сложить числа 4 и 3. Ответ, разумеется, — 7. Необходимо в уме перемножить числа 7 и 9. Ответ, конечно, — 63. Но если не знаете таблицу умножения, то надо выполнить нестандартное преобразование в виде многократного сложения. Трудно ли оно для вас? Необходимо в уме перемножить числа 289 и 347. Если вы не феноменальный счетчик, то хватит ли в вашей голове оперативной памяти? А сможете ли вы перемножить в уме шестизначные числа? Но если декомпозировать данную задачу на вычисление ряда произведений одного из сомножителей на отдельные цифры другого сомножителя и затем найденные произведения сложить (при этом записывать на бумаге все промежуточные результаты), то с этой задачей вполне может справиться заурядный человек.

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

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

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

1. Цикл разработки и его этапы

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

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

1.1 Каскадный цикл

• Подготовка
• Проектирование структуры программы
• Дизайн
• Кодирование
• Тестирование и отладка
• Документирование
• Внедрение программы
• Сопровождение программы
• Утилизация

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

Проектирование — это разработка проекта, процесс создания спецификации, необходимой для построения в заданных условиях еще несуществующего объекта на основе первичного описания этого объекта. Результатом проектирования является проектное решение или совокупность проектных решений, удовлетворяющих заданным требованиям. Заданные требования обязательно должны включать форму представления решения.
Дизайн — получение графических макетов, визуальных форм, разработка интерфейсов. Создание индивидуального стиля. 
Кодирование — получение исходного кода. 
Тестирование — проверка программы на соответствие всем предъявляемым к ней требованиям. 
Документирование — получение возможности передачи накопленных знаний другим разработчикам.
Внедрение — установка программного обеспечения, обучение пользователей. 
Сопровождение — исправление выявленных ошибок, поддержка пользователей.

Остановимся детально на процессе формирования тз и проектирования.

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

1. Описание: совместная работа заказчика (говорит о пользе продукта, требованиях к работоспособности и внешнему виду) и исполнителя (предлагает технические и алгоритмические решения).
2. Архитектура: утверждается язык программирования, база данных, серверы и фреймворки.
3. Техническое задание: составляется архитектором на основании описания и ответов заказчика на вопросы, согласовывается с менеджером проекта, затем передается клиенту, производятся правки.
4. Макеты (добавляются к техзаданию): интерфейсов, принципиальные схемы устройства, диаграммы структуры базы данных, схемы взаимодействия компонентов.
5. Контроль: архитектор устраняет замечания менеджера проектов.
6. Утверждение: заказчик проверяет и меняет ТЗ самостоятельно или сообщает список правок проект-менеджеру, замечания устраняются, ТЗ утверждается и прилагается к контракту.

При проектировании ПО заранее разработчик имеет возможность:

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

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

1. Что делаем (описание продукта, функционала, пользователей)?
2. Как делаем (архитектура)?
3. Как проверить, что цель достигнута (тестирование, критерии оценки)?

1.2 Гибкий цикл

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

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

Рисунок 1 – Этапы разработки по методологии Agile

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

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

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

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

Рисунок 2 – Наглядное сравнение каскадного и гибкого цикла

RUP

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

• Новация №1, заложенная в её основу, это «Бизнес-моделирование» и связанные с ним Сценарии Использования (Use Case).
  
  Сперва разрабатывается бизнес-сценарий использования, где будущая система представляет собою «чёрный ящик», который удовлетворяет все потребности Пользователя/Бизнеса. На его основе разрабатываются системные сценарии использования, описывающие функции системы, которые будут поддерживать выполнение бизнес-сценария.
• Новация №2: На основе выделенных системных сценариев использования системы принимаются архитектурные решения и выделяются компоненты, которые будут поддерживать бизнес-сценарии и решается будут ли они использоваться совместно для поддержки нескольких бизнес-сценариев или останутся заточенными под конкретный сценарий. (Объектно-ориентированное проектирование и программирование)
• Новация №3: Наличие выделенных сценариев использования системы позволяет разделить их на первичные и вторичные. Вторичные основываются на результатах выполнения первичных сценариев, которые по большому счёту самодостаточны. Отсюда появляется возможность выделить итерации и разложить реализацию всех сценариев по ним.

Рисунок 3 – Схематичное представление RUP

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

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

Каждая итерация в RUP это классический Waterfall, содержащий все 5 этапов работ по сбору требований и их анализу, проектированию, разработке, тестированию и доставке. Но RUP также вводит такое понятие как фазы для проекта: Сбор требований и Анализ, Проектирование, Построение, Внедрение.

• Первая итерация, Фаза Анализ
  Посвящена сбору требований будущих пользователей к системе. Пользователи рассказывают каждый свой кусочек работы (сценарий использования системы пользователем), а Аналитик из отдельных операций и процедур пытается собрать целый рабочий процесс. Цель этой итерации выйти на бизнес-сценарий использования системы / будущий бизнес-процесс на основе ИС. Их может быть больше чем один, поэтому не стоит замыкаться на том чтобы был обязательно один.

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

• Вторая итерация, Фаза Анализ
  
  После того как бизнес сценарии определены, собранные требования раскладываются по шагам бизнес-сценария и системным сценариям. На этом этапе также выявляются те шаги бизнес-сценариев, что были не выявлены в первой итерации. 

Результатом этой итерации становятся:

• • На 90% законченные бизнес-сценарии.
  • Намеченные, но не детализированные системные сценарии использования по каждому бизнес-сценарию.
  • Собранные требования структурированы по бизнес и системным сценариям.
• Третья итерация, Фаза Проектирование
  Выявленным бизнес сценариям выставляются приоритеты реализации и самые важные из них становятся предметом проработки на данной итерации. В отобранных бизнес-сценариях выделяются первичные шаги-этапы, которые являются базой для всех последующих и без которых реализация остальных не имеет смысла. Для этих этапов детализируются сценарии использования системы.
  
  Законченный результат передается Системным Аналитикам и Архитектору для моделирования того, что будет происходит внутри системы. Выделяются классы, кооперации между ними, последовательности взаимодействия. Формируется базовое представление об архитектуре будущей системы, выделяются подсистемы, компоненты системы и их распределение по узлам ИТ-решения.
  
  Уже в этой итерации могут быть начаты работы по разработке и результатом итерации станет готовый прототип, поддерживающий выполнение первичных шагов-этапов ключевого бизнес-сценария. Его уже можно показывать пользователям для сбора обратной связи и уточнения требований.
  
  Этот прототип не передается в опытную или промышленную эксплуатацию, так как заложенная в основу архитектура является первым пробным шаром и в последующих итерациях будет скорректирована.
• Четвертая итерация, Фаза Проектирование
  Стартует параллельно третьей итерации, когда в ней закончены работы по анализу и начаты работы по проектированию.
  На этой итерации происходит проработка первичных шагов-этапов остальных бизнес-сценариев. Причина по которой прорабатываются они, а не последующие шаги для ключевых бизнес-сценариев, это определение будущей архитектуры всей программы. 
  
  Каждый бизнес-сценарий может потребовать для своей реализации каких-то специфических компонент будущей системы и по этой причине архитектурные решения для каждого бизнес-сценария должны быть согласованы между собой.
  
  Результатом этой итерации станут:
  • Архитектурные решения для каждого бизнес-сценария.
  • Согласованный проект общей архитектуры системы 1.0
  • Вторая версия прототипа с готовыми первыми шагами вторичных бизнес-сценариев в дополнение к первым шагам ключевого бизнес-сценария.
• Пятая итерация, Фаза Построения
  Стартует параллельно четвертой итерации, когда в ней закончены работы по анализу и начаты работы по проектированию. Предполагается, что к моменту старта итерации уже получена обратная связь по результатам тестирования пользователями прототипа, изготовленного во время третьей итерации. Здесь происходит проработка остальных шагов-этапов ключевого бизнес-сценария и связанных с ними системных сценариев использования.
  
  Предполагается, что к моменту начала этапа работ «Проектирование», уже будет выполнена реализация (разработка) четвертой итерации и начато тестирование второй версии прототипа.
  Происходит уточнение согласованного проекта общей архитектуры системы после которого внесение каких-то концептуальных изменений в него практически сводится к нулю, но всё ещё возможно, так как остаются не реализованными полностью вторичные бизнес-сценарии.
  
  Результатом итерации становятся:
  • Полностью реализованный ключевой бизнес сценарий.
  • Согласованный проект общей архитектуры системы 2.0
  • Третья версия системы, реализующая ключевой бизнес-сценарий и первые шаги для вторичных бизнес-сценариев.