Проектирование программных систем. Занятие 1

МАИ, каф 806, ППС

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

методологии

1

МАИ, каф 806, ППС2

Базовые понятия. Экономические аспекты

• Стратегия увеличения прибыли от проекта

Уменьшение расходов;

Увеличение прибыли от проекта (маркетинг);

Платить позже, получать прибыль раньше (мы платим меньше по процентам);

Увеличение вероятности что проект останется жить (т.е. мы сможем получать прибыль от проекта и впредь).

• Основные показатели разработки ПО и связи между ними

Время

Цена

Качества

Объем работ


Базовые понятия. Экономический дизайн

Архитектура - это баланс между:

техническим решением;

бизнес задачей;

социальным аспектом (участники проекта);

Изменения касающиеся одного направления зачастую касается другого (технические изменения могут касаться бизнеса и т.д.)

Все решения должны быть:

Практичные (их можно использовать прямо сейчас);

Легко реализуемы (сложное решение дорого реализуется);

Базируются на принципах (понятно, какое решение какой цели добивается);

Легко обоснуемте;


Базовые понятия. Экономический дизайн

Хорошие технически решения зачастую противоречат экономическим показателям (дорогие и долгие)

Базовый принцип:

80% функциональности делается 20% доработок

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

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


Базовые понятия. Риски при разработке ПО

Отставание от графика проектанебольшие циклы выпуска версий (1-4 недели). Задачи на 1-3 дня.

Отмена проектазаказчик определяет минимальный объем работ, для максимальной бизнес отдачи.

Невозможность модификации системы после сдачи (высокая трудоемкость)автоматизация тестирования позволяет поддерживать качество

Большое число ошибок в ПОна всех уровнях производится контроль качества (программеры на уровне кода), заказчики на уровне функциональности

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

Изменение бизнесаНебольшие циклы выпуска версий

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

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


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

6


Базовые понятия. Основные ценности XP

Общение

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

Простота

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

Обратная связь

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

Смелость

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

Уважение

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


Базовые понятия. Основные принципы XP

Взаимная выгода

Сходство

Все лучше и лучше

Разнообразие

Обдумывание

Течение

Новые возможности

Избыточность

Неудачи

Качество

Маленькими шажками

Ответственность


ПЛАНИРОВАНИЕXP

9

ПЛАНИРОВАНИЕ


Базовые понятия. Практики XP.Анализ требований и планирование [1/2]

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

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

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

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


Базовые понятия. Практики XP.Анализ требований и планирование [2/2]

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

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

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

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


ЧЕЛОВЕЧЕСКИЙ ФАКТОРXP

12

ЧЕЛОВЕЧЕСКИЙ ФАКТОР


Базовые понятия. Практики XP.Команда и человеческий фактор [1/2]

Работа в одном помещениикоманда разработчиков должна сидеть в одном большом помещении – это облегчает общение.

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

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

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


Базовые понятия. Практики XP.Команда и человеческий фактор [2/2]

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

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

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


ПРОЕКТИРОВАНИЕXP

15

ПРОЕКТИРОВАНИЕ


Базовые понятия. Практики XP.Проектирование [1/2]

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

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


Базовые понятия. Практики XP.Проектирование [2/2]

Сначала тестыперед тем, как редактировать старый код или писать новый, нужно написать тесты, которые будут его проверять. Это поможет решить четыре проблемы: «Программирование по-ковбойски»: во время написания кода так легко

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

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

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

течение нескольких часов. Если вы приучите себя к ритму «тест, код, рефакторинг, тест, код, рефакторинг», этого никогда не случится.


ПРОГРАММИРОВАНИЕXP

18

ПРОГРАММИРОВАНИЕ


Базовые понятия. Практики XP.Программирование и выпуск продукта

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

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

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

Общий кодлюбой член команды может в любой момент изменить любую часть системы. Эта практика называлась в прежней версии ХР «коллективное владение кодом».

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

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


Модели процессов

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

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


Модель процессов MSF

Симбиоз водопадной и спиральной модели

Модель процессов MSF состоит из пяти четко определенных этапов:

создания общей картины приложения;

планирования;

разработки;

стабилизации;

развертывания.

Каждый этап завершается контрольной точкой.

Мы рассмотрим только основные моменты первых двух этапов.

21


Роли в модели команд MSF

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

Менеджер программы (program management) несет ответственность за разработку и поставку решения заказчику в полном соответствии с ограничениями проекта.

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

Тестировщик (testing)отвечает за выявление и устранение всех неполадок и проблем с качеством продукта и дает окончательное ≪добро≫ на выпуск и поставку решения.

Менеджер по выпуску (release management) отвечает за развертывание и работу продукта. Он проверяет корректность инфраструктуры и определяет возможность развертывания и поддержки продукта.

Специалист по удобству использования (user experience) анализирует потребности и проблемы, возникающие у пользователей, и оценивает продукт напредмет соответствия таким потребностям.

22


MSF . Управление компромиссами

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

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

Учитывая, что зафиксировано _______ , мы определим ________ и в случае необходимости скорректируем.

Например, «Учитывая, что зафиксированы ресурсы, мы определим график и в случае необходимости скорректируем функциональность»

23


MSF . Порядок применения итераций в проектах

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

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

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

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

24


MSF .Управление рисками

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

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

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

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

Управление рискамипроцесс исполнения планов мероприятий по управлению и устранению рисков и отчетность о состоянии дел в этой сфере.

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

25


MSF . Создание общей картины решенияподробнее будет рассмотрено в отдельной теме

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

Результаты

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

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

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

26


MSF . Сбор и анализ бизнес-требованийподробнее будет рассмотрено в отдельной теме

Сбор и анализ бизнес-требований:

анализ текущего состояния предприятия и анализ бизнес-требований решения;

Сбор и анализ пользовательских требований

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

определение требований по поддержке других языков и локализации;

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

Сбор и анализ системных требований:

определение требований по сопровождению и поддержке;

определение требований по масштабированию, доступности, надежности развертыванию, безопасности;

Сбор и анализ требований к оборудованию, ПО и сетевой инфраструктуре:

определение требований по интеграции;

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

системного ПО и сетевой инфраструктуры;

анализ влияния решения на ИТ-среду

27


MSF . Планирование

Кульминация этапа планирования— контрольная точка ≪утверждение плана проекта≫

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

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

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

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

28


MSF . Разработка спецификаций

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

выбор стратегии разработки;

выбор стратегии развертывания;

выбор стратегии обеспечения безопасности;

выбор стратегии поддержки и сопровождения;

создание плана тестирования;

создание плана обучения пользователей

29

Тип дизайна Представление ЦельКонцептуальный Представление проблемы с точки

зрения пользователя и бизнесаОписание проблемы и решенияв терминах сценариевиспользования системы

Логический Представление решения с точки зрения команды проекта

Описание решения как логическогонабора взаимодействующих сервисов

Физический Представление решения с точки зрения разработчиков

Описание сервисов и технологийрешения


MSFКонцептуальный дизайн

На стадии анализа выполняются следующие задачи:

уточнение диаграмм ВИС;

выбор подходящей прикладной архитектуры решения;

создание концептуальной модели решения.

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

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

Существует несколько видов сервисов, предоставляемых решением: пользовательские сервисы, сервисы данных и системные сервисы.

30

Сервис Пример

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

Системный Сервис размещения заказа

Данных Сервис информации о заказе


MSFЛогический дизайн

Логический дизайн — это процесс описания продукта в терминах организации, структуры, синтаксиса и взаимодействия его частей с точки зрения проектной команды.

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

стадии анализа, во время которой определяются бизнес-объекты, сервисы, атрибуты и отношения между объектами;

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

Результаты логического дизайна таковы:

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

высокоуровневый дизайн пользовательского интерфейса;

логическая модель данных.

31


MSFФизический дизайн

Физический дизайн — это процесс описания компонентов, сервисов и технологий решения сточки зрения разработчиков (программистов).

Цели физического дизайна:

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

определить технологии, оптимальные для программирования;

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

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

диаграммы классов;

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

базовую модель развертывания;

модель программирования (тактики);

спецификации компонентов.

К базовым результатам стадии исследования относятся:

существующая топология сети;

существующая топология данных;

существующая топология компонентов;

32

Education

Проектирование программных систем. Занятие 1