1. Структура и разновидности процесса разработки программного обеспечения

Разновидности процесса разработки ПО

Модель водопада

Модель водопада (waterfall model или последовательная разработка) – самый известный, исторически появившийся одним из первых процесс разработки. Он был описан в статье Ройса (W.W.Royce) в 1970 году (на самом деле, Ройс критиковал этот процесс, предлагая в качестве альтернативы итеративную разработку). Основная идея заключается в том, что процесс разработки делится на четко определенные фазы, выполняемые строго последовательно. Название «водопад» появилось из-за внешнего вида диаграммы, изображающей процесс:

Классическая водопадная модель включает следующие области:

• Разработка требований (requirements): сбор бизнес-требований заказчика и их преобразование в функциональные требования к программному продукту.

• Анализ и дизайн (analysis and design): разработка модели предметной области (domain model), проектирование схемы базы данных, объектной модели, пользовательского интерфейса и т.п.

• Реализация (implementation): создание продукта по спецификациям, разработанным на предыдущем этапе.

• Тестирование (testing): включает проверку соответствия функциональности программного продукта потребностям пользователей (validation), а также поиск дефектов в реализации.

• Развертывание (deployment): обучение пользователей, инсталляция системы, перевод в промышленную эксплуатацию.

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

Насколько эффективным оказался такой подход? Он хорошо работает в проектах, где требования могут быть четко определены и зафиксированы. В таких проектах модель водопада позволяет обеспечить заданный уровень качества (который может быть весьма высоким) и соблюдать бюджетные и временные ограничения. Благодаря этому она часто используется в больших организациях (таких как Министерство обороны США и NASA) при строгих требованиях к надежности создаваемого ПО.

Однако практика показала следующие недостатки этого процесса:

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

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

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

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

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

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

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

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

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

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

Другие модели разработки, основанные на водопадной моделе: Rational Unified Process (RUP), Унифицированный процесс разработки программного обеспечения (USDP).

Таблица 1.1. Издержки процессов разработки

Фактор	Водопадный процесс	Итеративные процессы
		Спиральный	Инкрементальный
Легкость контроля документации	Легче	Тяжелее	Тяжелее/Средне (пояснение 1)
Возможность взаимодействия с заказчиком	Тяжелее	Легче	Легче
Поддержание хорошего проектирования	Средне/Легче	Легче (пояснение 2)	Тяжелее
Сбор метрических данных, собранных в ходе проекта	Тяжелее	Средне/Легче	Средне/Легче

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

Гибкие методологии

В течение 1990-х годов все больше разработчиков ПО начинали искать альтернативу традиционным, как правило, основанным на модели водопада, процессам разработки. К 2000 году существовало уже целое множество так называемых легковесных (lightweight) методологий.

В 2001 году группа создателей и экспертов по различным легковесным методологиям провела семинар, на котором были сформулированы основные принципы гибкой разработки ПО. На том же семинаре было предложено новое название легковесных методологий – гибкая разработка (agile software development).

Общими особенностями гибких методологий являются:

• Ориентированность на людей – как разработчиков, так и заказчиков. Считается, что умение собрать в проектной команде «правильных» людей определяет успех или неудачу проекта в значительно большей степени, чем любые процессы или технологии.

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

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

• Ожидание изменений – в гибком процессе проектная команда не пытается зафиксировать требования в начале проекта и затем следовать жестко определенному плану. Изменения могут быть сделаны на сколь угодно позднем этапе проекта.

CMMI

Модель Capability Maturity Model Integration была разработана в течение 1990-х годов в университете Карнеги-Меллона (Carnegie Mellon University.) совместно с Software Engineering Institute (SEI) и другими организациями. Одним из главных спонсоров разработки стало Министерство обороны США.

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

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

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

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

• Важная, а часто и определяющая причина для внедрения CMMI – возможность официальной сертификации на достижение определенного уровня зрелости. Нередко наличие или отсутствие сертификации по CMMI является решающим фактором в выборе компании-подрядчика.

2. Применение системного анализа при проектировании программных систем.

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

Законы взаимодействия:

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

3. Понятие сложности программной системы.

Причины сложности:

Из-за расплывчатости переходовIi, Vi, Ij, Kj происходит серьезное отличие Pz (представление инженера по знаниям) от Og (эксперт).

Эта расплывчатость зависит от формализации предметной области.

• Передача информации, конфликты сотрудников

• Чем больше делаешь, тем больше углубляешься в проблемы

• Кто решает как менять систему: главный центр или весь коллектив работающих людей.

• Состав поменяется и освоение новых зависит от документированности проекта.

(первые 2 пункта – заказчик, вторые –разработчик)

!!!Отсутствуют согласованные стандарты на все этапы разработки программной системы.

• проблемы частей системы и всей в целом.

• от обобщенного к более конкретному

• варианты возможных проблем

• предсказать поведение системы невозможно

4. Назначение и элементы объектной модели.

Элементы объектной модели:

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

Выделение «деталей» внутри кота.

Иерархичность – упорядочение абстракций, расположение их по уровням (игрушка мышь – ее составные части – детали – атомы -…)

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

Преимущества объектной модели:

Во-первых, позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.

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

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

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

5. Понятие объекта и класса.

Объект – нечто, имеющее четко очерченные границы. Объект представляет собой опознаваемый предмет, единицу или сущность (реальную/абстрактную), имеющую четко определенное функциональное значение.

Состояние – перечень всех св-в предмета и их текущего значения.

Поведение – то, как предмет реагирует и действует; выражается в терминах состояния и передачи сообщений.

Идентичность – св-во объекта, которое отличает его от всех других объектов.

Класс – множество объектов, имеющих общую структуру и общее поведение.

Укласса есть атрибуты и операции (своеобразное обобщение состояний и поведений одинаковых объектов).

Отношения между классами и объектами:

• Имя (опционально);

• Множественность;

• Ограничения (для пары/нескольких отношений);

• Классификаторы;

• Навигация.

Отношения между объектами:

• Связи (над связью указывается роль объекта, типология связи). Роли: сервер, клиент, агент.

• Агрегация.

Отношения между классами: зависимости; ассоциации; обобщения; реализации.

6. Методы оценки качества объектной модели. Метрики.

Метрики объектно-ориентированных программных систем

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

Метрические особенности объектно-ориентированных программных систем

Объектно-ориентированные метрики вводятся с целью:

- улучшить понимание качества продукта;

- оценить эффективность процесса конструирования;

- улучшить качество работы на этапе проектирования.

Все эти цели важны, но для программного инженера главная цель — повышение качества продукта. Возникает вопрос — как измерить качество объектно-ориенти­рованной системы?

Для любого инженерного продукта метрики должны ориентироваться на его уни­кальные характеристики. Например, для электропоезда вряд ли полезна метрика «расход угля на километр пробега». С точки зрения метрик выделяют пять харак­теристик объектно-ориентированных систем: локализацию, инкапсуляцию, ин­формационную закрытость, наследование и способы абстрагирования объектов. Эти характеристики оказывают максимальное влияние на объектно-ориентиро­ванные метрики.

7. Назначение и область применения языка UML.

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

1. Описание структуры

2. Описание динамики взаимодействия объектов

3. Управление моделями

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

Область	Представления	Диаграммы
Структурная	Статистическое	классов
	Использования	использования
	Программной реализации	компонентов
	Развертывания	развертывания
Динамическая	В виде конечного автомата	состояний
	Деятельности	деятельности
	Взаимодействия	последовательности
		кооперации
Управление моделью	Управления моделью	классов

UML (Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, которая называется UML моделью. UML был создан для определения, визуализации, проектирования и документирования по большей части программных систем.

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

UML позволяет разработчикам ПО достигнуть консенсуса в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

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

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

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

Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

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

UML получил широкое распространение и динамично развивается.

Критика UML:

• Избыточность языка. Неоправданно большой и сложный;

• Неточная семантика. Т.к. UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений - формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные;

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

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

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

8. Языка UML. Назначение и элементы диаграммы классов.

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

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

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

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

Обобщение (Generalization) - это отношение между общей сущностью (суперклассом, или родителем) и ее конкретным воплощением (субклассом, или потомком). Обобщения иногда называют отношениями типа "является", имея в виду, что одна сущность является частным выражением другой, более общей. Обобщение означает, что объекты класса-потомка могут использоваться всюду, где встречаются объекты класса-родителя, но не наоборот. Другими словами, потомок может быть подставлен вместо родителя. При этом он наследует свойства родителя, в частности его атрибуты и операции. Часто, хотя и не всегда, у потомков есть и свои собственные атрибуты и операции, помимо тех, что существуют у родителя. Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя; это свойство называютполиморфизмом (Polymorphism). Графически отношение обобщения изображается в виде линии с большой незакрашенной стрелкой, направленной на родителя. Применяйте обобщения, когда хотите показать отношения типа "родитель/потомок".Класс может иметь одного или нескольких родителей или не иметь их вовсе. Класс, у которого нет родителей, но есть потомки, называется базовым (base) или корневым (root), а тот, у которого нет потомков, - листовым (leaf). О классе, у которого есть только один родитель, говорят, что он использует одиночное наследование (Single inheritance); если родителей несколько, речь идет о множественном наследовании (Multiple inheritance).

Ассоциацией (Association) называется структурное отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа. Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. Вполне допустимы случаи, когда оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса позволительно связать другие объекты из того же класса. Ассоциация, связывающая два класса, называется бинарной. Можно создавать ассоциации, связывающие сразу несколько классов. Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами. Используйте ассоциации, когда хотите показать структурные отношения. Также существует 3 дополнения, применимых к ассоциациям.

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

Кратность. Ассоциации отражают структурные отношения между объектами. Часто при моделировании бывает важно указать, сколько объектов может быть связано посредством одного экземпляра ассоциации (то есть одной связи, см. главу 15). Это число называется кратностью (Multiplicity) роли ассоциации и записывается либо как выражение, значением которого является диапазон значений, либо в явном виде, как показано на рис. 5.6. Указывая кратность на одном конце ассоциации, вы тем самым говорите, что на этом конце именно столько объектов должно соответствовать каждому объекту на противоположном конце. Кратность можно задать равной единице (1), можно указать диапазон: "ноль или единица" (0..1), "много" (0..*), "единица или больше" (1..*). Разрешается также указывать определенное число (например, 3).

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

Агрегирование. Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием; оно причислено к отношениям типа "имеет" (с учетом того, что объект-целое имеет несколько объектов-частей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с не закрашенным ромбом со стороны "целого".

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

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