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

1. ПРОЕКТИРОВАНИЕ
ПРОГРАММНЫХ СИСТЕМ
ДЗЮБА ДМИТРИЙ ВЛАДИМИРОВИЧ, СТАРШИЙ
ПРЕПОДАВАТЕЛЬ КАФ. 806
DDZUBA@YANDEX.RU

2. Базовые требования к слушателям
1. Знание языка программирования
при изложении материала будем считать, что слушатель знает основные конструкции
современных языков программирования и умеет конструировать алгоритмы
2. Знание операционной системы Microsoft Windows 7/Windows 8.1
практические занятия будут проходить на компьютерах, работающих под управлением
Microsoft Windows 7

3. Цель курса
После изучения курса “Проектирование программных систем” студент должен знать:
• Технологии анализа сложных систем
• Принципы проектирования пользовательских интерфейсов;
• Принципы моделирования программных систем;
Он должен уметь:
• Проводить анализ сложных предметных областей;
• Конструировать прототипы пользовательских интерфейсов программ;
• Строить модели сложных программных систем;

4. Структура курса
1. Принципы гибких методологий разработки
Базовые правила методологии экстремального программирования.
2. Моделирование на языке UML
Основы языка UML и моделирование в среде Sparx Enterprise Architect
3. Usability и дизайн
Понятие Usability. Подходы к проектированию пользовательских интерфейсов. Графический
дизайн. Интерактивный дизайн.
4. Разработка концептуальных требований
Принципы формирования требований к программным системам. Документирование
требований. Управление изменениями в требованиях.
5. Разработка Архитектуры ПО
Архитектура ПО, экономические аспекты разработки архитектуры ПО. Атрибуты качества ПО.
Тактики по достижению требуемого качества ПО.
6. Паттерны проектирования
Паттерны для создания объектов. Паттерны для организации структуры объектов. Паттерны
для описания поведения объектов.

5. Дополнительная литература
1. Карл Вигерс, «Разработка требований к программному обеспечению». М. «Русская редакция», 2004
2. Басс Л., Клементс П., Кацман Р. Архитектура программного обеспечения на практике. 2-е издание. —
СПб.: Питер, 2006. — 575 с.: ил.
3. Буч Г. Объектно-ориентированное проектирование с примерами приложений на С++. - М.:
Издательство Бином, СПб.: Невский диалект, 1999
4. Learning UML 2.0 , By Kim Hamilton, Russell Miles, Publisher: O'Reilly, April 2006
5. Бек К. Экстремальное программирование. М.: Питер, 2002
6. Ivar Jacobson, Pan-Wei Ng, Aspect-Oriented Software Development with Use Cases, Addison Wesley
Professional, 2004
7. Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord,
Judith Stafford; Documenting Software Architectures. Views and Beyond.Second Edition; Addison
Wesley;2010; ISBN-10: 0-321-55268-7

6. Отчетность по курсу
1. Расчетная работа, включающая в себя:
◦ Спецификацию требований к разрабатываемой системе;
◦ Прототипы пользовательских интерфейсов;
◦ Архитектуру ПО;
2. Расчетная работа сдается на электронном и бумажном носителе.
3. Зачет с оценкой .

7. Экономика разработки программного
обеспечения

8. Экономические аспекты
• Стратегия увеличения прибыли от проекта
◦ Уменьшение расходов;
◦ Увеличение прибыли от проекта (маркетинг);
◦ Платить позже, получать прибыль раньше (мы платим меньше по процентам);
◦ Увеличение вероятности что проект останется жить (т.е. мы сможем получать прибыль от
проекта и впредь).
• Основные показатели разработки ПО и связи между ними
◦ Время
◦ Цена
◦ Качества
◦ Объем работ
8

9. 9
Экономический дизайн
Архитектура - это баланс между:
◦ техническим решением;
◦ бизнес задачей;
◦ социальным аспектом (участники проекта);
Изменения касающиеся одного направления зачастую касается другого (технические
изменения могут касаться бизнеса и т.д.)
Все решения должны быть:
◦ Практичные (их можно использовать прямо сейчас);
◦ Легко реализуемы (сложное решение дорого реализуется);
◦ Базируются на принципах (понятно, какое решение какой цели добивается);
◦ Легко обоснуемте;

10. 10
Экономический дизайн
Хорошие технически решения зачастую противоречат экономическим показателям
(дорогие и долгие)
Базовый принцип:
80% функциональности делается 20% доработок
Необходимо задать вопрос о степень используемости разрабатываемого дизайна (чем в
больших задача может использоваться - тем выгоднее). Степень используемости зависит от
бизнеса (Если функция не используется, то ей не обязательно быть хорошей)
Необходимо определить атрибуты качества архитектуры. (производительность,
надежность, безопасность, отказоустойчивость).

11. 11
Риски при разработке ПО
1. Отставание от графика проекта
2. Отмена проекта
3. Невозможность модификации системы после сдачи (высокая
трудоемкость)
4. Большое число ошибок в ПО
5. Неправильное понимание требований бизнеса
6. Изменение бизнеса
7. Не использование запрограммированой функциональности заказчиком
8. Увольнение ключевых программистов

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

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

14. 14
Основные принципы XP
1. Взаимная выгода
2. Сходство
3. Все лучше и лучше
4. Разнообразие
5. Обдумывание
6. Течение
7. Новые возможности
8. Избыточность
9. Неудачи
10. Качество
11. Маленькими
шажками
12. Ответственность

15. 1. ПЛАНИРОВАНИЕ
15

16. 16
Анализ требований и планирование [1/2]
«Рассказы»
функциональность приложения описывается короткими «рассказами», в которых работа системы изложена с
точки зрения заказчика. Эти «рассказы» также являются основной движущей силой разработки приложения.
Еженедельный цикл
вся разработка проекта происходит в виде череды еженедельных циклов. В начале недели происходит собрание,
на котором заказчик выбирает, какие «рассказы» надо сделать за эту неделю.
Ежеквартальный цикл
планирование в большем масштабе происходит каждый квартал. Оно состоит из обсуждений работы команды и
темпов разработки.
Слабина
избегайте обещаний, которые не сможете выполнить. В любой план включайте задачи, которые вы сможете
выкинуть, если не будете укладываться в срок. В этом случае у вас будет выход даже в случае непредвиденных
проблем.

17. 17
Анализ требований и планирование [2/2]
Непосредственное вовлечение заказчика
люди, для которых вы пишете программный продукт, должны стать частью команды и вносить свою лепту в
ежеквартальное и еженедельное планирование.
Инкрементная поставка продукта
когда вам предстоит целиком сменить существующую систему, начинайте процесс с изменения нескольких
функций, и так постепенно замените всю систему. Избегайте подхода, который можно выразить словами «Все или
ничего!»
Контракт с оговоренным объемом работ
контракт на разработку программного обеспечения включает в себя время, затраты и качество системы, однако
точные объемы этой системы надо оговаривать в процессе работы. Заключив с заказчиком серию небольших
контрактов, можно значительно снизить риски.
Плата за использование
обычно заказчик платит за каждый выпуск программного продукта. Это нередко дает повод для конфликтов
между разработчиками и заказчиком, который хочет внести как можно больше новой функциональности в
наименьшее количество выпусков продукта. Если исчислять деньгами непосредственную работу над
функциональностью, заказчик будет получать более точную и своевременную информацию, и сможет точнее
направлять разработку продукта.

18. 2. ЧЕЛОВЕЧЕСКИЙ ФАКТОРP
18

19. 19
Команда и человеческий фактор [1/2]
Работа в одном помещении
команда разработчиков должна сидеть в одном большом помещении – это облегчает общение.
Команда как одно целое
команда должна состоять из людей, обладающих всеми необходимыми для проекта навыками и знаниями. Всех
их должно объединять чувство принадлежности общему делу, они должны всячески поддерживать друг друга.
Информативность окружения
в рабочем помещении должны быть информативные постеры и прочие наглядные пособия, которые показывали
бы статус проекта и другую информацию о проделанной работе.
Энергичная работа
люди не должны быть истощены работой, им надо сохранять свежесть и энергичность, чтобы фокусироваться на
задачах и уметь эффективно их решать. Следовательно, надо жестко ограничить сверхурочную работу, так чтобы у
каждого оставалось время и на личную жизнь. В прежней версии методологии это называлось «приемлемый
темп разработки».

20. 20
Команда и человеческий фактор [2/2]
Парное программирование
код всегда пишут два программиста, сидящих за одним компьютером.
Постоянство
команда разработчиков должна работать в одном и том же составе на протяжении нескольких проектов. Те связи,
которые возникают между людьми, воистину бесценны, поэтому старайтесь перераспределять людей как можно
реже.
«Усушка и утряска»
если команда становится все более продуктивной, не увеличивайте ее нагрузку. Оставьте объем работ прежним,
но выделите свободных членов этой команды с тем, чтобы они создавали свои собственные новые команды.

21. 3. ПРОЕКТИРОВАНИЕ
21

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

23. 23
Проектирование [2/2]
Сначала тесты
перед тем, как редактировать старый код или писать новый, нужно написать тесты, которые будут его проверять.
Это поможет решить четыре проблемы:
◦ «Программирование по-ковбойски»: во время написания кода так легко увлечься и начать писать код для
всех задач подряд, которые приходят на ум. Если же сначала написать тесты, которые затем будут
проверять код, нам волей-неволей придется сосредоточиться на задаче, которую мы пытаемся решить, а
также проверить, насколько правильно мы спроектировали данную часть системы.
◦ Слаженность и единство: если написать тест трудно, значит, у вас проблемы с дизайном системы, а не с
тестированием или программированием. Когда программный код разбит на функционально связанные
модули с минимальным количеством двусторонних зависимостей между ними, тестировать его не
составит большого труда.
◦ Доверие: если вы пишете код, который работает, и документируете его с помощью автоматизированных
тестов, ваши коллеги будут доверять вам.
◦ Ритм: во время программирования можно легко увлечься и блуждать в коде в течение нескольких часов.
Если вы приучите себя к ритму «тест, код, рефакторинг, тест, код, рефакторинг», этого никогда не
случится.

24. 4. ПРОГРАММИРОВАНИЕ
24

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

26. ВОДОПАДНАЯ
МОДЕЛЬ
ТЕМНАЯ СТОРОНА

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

28. Зачем нужна водопадная модель?
1. Проекты с фиксированной ценой (fix price contract)
В государственных учреждениях и крупных корпорациях ИТ проекты
заранее бюджетируются и происходит фиксация цены и сроков. В таких
проектах надо заранее очень подробно обговорить с заказчиком, что он
получит за предлагаемые деньги.
2. Высокая цена ошибки.
Проработка технических спецификаций позволяет заранее
спрогнозировать как функциональное так и не-функциональное
поведение системы.

29. Откуда взялся Waterfall?
Каскадная модель (англ. waterfall model,
иногда переводят, как модель
"Водопад") — модель процесса
разработки программного обеспечения,
в которой процесс разработки выглядит
как поток, последовательно проходящий
фазы анализа требований,
проектирования, реализации,
тестирования, интеграции и поддержки.
В качестве источника названия часто
указывают статью, опубликованную
У. У. Ройсом (W. W. Royce) в 1970 году;
при том, что сам Ройс использовал
итеративную модель разработки.
* http://wikipedia.org/

30. Модель процессов MSF
Симбиоз водопадной и спиральной модели
Модель процессов MSF состоит из пяти
четко определенных этапов:
◦ создания общей картины приложения;
◦ планирования;
◦ разработки;
◦ стабилизации;
◦ развертывания.
Каждый этап завершается контрольной
точкой.
Мы рассмотрим только основные моменты
первых двух этапов.
30

31. Роли в модели команд MSF
Менеджер решения (product management)
отвечает за управление связями с клиентом. На этапе проектирования на эту роль возлагается сбор клиентских
требований и контроль за тем, чтобы они соответствовали и удовлетворяли все потребности бизнеса. Менеджер
решения также работает над планом связей с клиентом в процессе создания и реализации проекта.
Менеджер программы (program management)
несет ответственность за разработку и поставку решения заказчику в полном соответствии с ограничениями проекта.
Разработчик (development)
обеспечивает разработку технологического решения в соответствии со спецификациями, предоставленными
менеджерами решения.
Тестировщик (testing)
отвечает за выявление и устранение всех неполадок и проблем с качеством продукта и дает окончательное ≪добро≫ на
выпуск и поставку решения.
Менеджер по выпуску (release management)
отвечает за развертывание и работу продукта. Он проверяет корректность инфраструктуры и определяет возможность
развертывания и поддержки продукта.
Специалист по удобству использования (user experience)
анализирует потребности и проблемы, возникающие у пользователей, и оценивает продукт на предмет соответствия
таким потребностям.
31

32. MSF . Управление компромиссами
Иногда в проектах возможны нарушение графиков или
перерасход бюджета. Главная причина подобных проблем —
нечетко описанная область действия проекта. Область
действия (scope) определяет, какие задачи решает продукт, а
какие не относятся к его компетенции.
Матрица компромиссов проекта — инструмент, который
команда и заказчик используют при принятии решений о
компромиссах. Подобные решения следует принимать на
ранних стадиях проекта.
Учитывая, что зафиксировано _______ , мы определим
________ и в случае необходимости скорректируем.
Например, «Учитывая, что зафиксированы ресурсы, мы
определим график и в случае необходимости скорректируем
функциональность»
32

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

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

35. MSF . Создание общей картины решения
подробнее будет рассмотрено в отдельной теме
На этой стадии команда, заказчик и спонсоры проекта определяют высокоуровневые
бизнес-требования и общие цели проекта. Главная задача — согласовать то, как видят
проект разные его участники, и выработать у членов команды единое мнение о
полезности проекта для компании и его реализуемости.
Результаты
◦ документ общей картины и области действия решения — описывает цели и ограничения
проекта. В нем перечислены параметры разрабатываемого продукта, требования, которым он
должен удовлетворять, его функции и предварительный календарный график работ; Основные
характеристики: конкретность, измеримость, реалистичность, насущность, точный расчет
времени.
◦ документ структуры проекта — описывает организационную структуру проекта и процесс
руководства проектом и определяет роли и обязанности каждого члена команды;
◦ документ оценки риска — содержит начальное определение и анализ рисков, связанных с
проектом, а также планы мероприятий по обеспечению непрерывности бизнеса
35

36. MSF . Сбор и анализ бизнес-требований
подробнее будет рассмотрено в отдельной теме
Сбор и анализ бизнес-требований:
◦ анализ текущего состояния предприятия и анализ бизнес-требований решения;
Сбор и анализ пользовательских требований
◦ определение вариантов использования системы;
◦ определение требований по поддержке других языков и локализации;
◦ определение требований по поддержке специальных возможностей
Сбор и анализ системных требований:
◦ определение требований по сопровождению и поддержке;
◦ определение требований по масштабированию, доступности, надежности развертыванию, безопасности;
Сбор и анализ требований к оборудованию, ПО и сетевой инфраструктуре:
◦ определение требований по интеграции;
◦ анализ ИТ-среды, в том числе существующих и будущих приложений, а также текущего и планируемого
оборудования,
◦ системного ПО и сетевой инфраструктуры;
◦ анализ влияния решения на ИТ-среду
36

37. MSF . Планирование
Кульминация этапа планирования— контрольная точка ≪утверждение плана проекта≫
Функциональные спецификации (базовые) описывают, что именно будет представлять из себя продукт.
Это итог усилий всей команды.
Генеральный план проекта (базовый) — это набор планов для каждой из шести ролей команды, они
ориентированы на обеспечение максимального соответствия функций решения и функциональных
спецификаций. Здесь описываются методы, которые команды предполагают применять для выполнения
своих задач.
Генеральный календарный график проекта (базовый) определяет временные рамки генерального плана
проекта и синхронизирует календарные графики, разработанные разными командами. В нем указывается
предполагаемое время выполнения работы отдельными командами. Объединяя отдельные календарные
графики, проектная команда создает единый календарный график проекта. Это первый шаг на пути к
определению конечной даты выпуска продукта.
Обновленный генеральный документ по оценке риска уже создан на этапе построения общей картины
решения и регулярно пересматривается и обновляется, особенно при прохождении контрольных точек.
Здесь описываются различные виды риска, связанного с разработкой решения. Обычно все риски
сортируются для выявления самых опасных из них и их оценки суммируются для получения обшей оценки
риска.
37

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

39. Итерационная разработка дизайна
Тип дизайна Представление Цель
Концептуальный Представление проблемы с
точки зрения пользователя
и бизнеса
Описание проблемы и решения
в терминах сценариев
использования системы
Логический Представление решения с
точки зрения команды
проекта
Описание решения как логического
набора взаимодействующих сервисов
Физический Представление решения с
точки зрения
разработчиков
Описание сервисов и технологий
решения

40. Концептуальный дизайн
На стадии анализа выполняются следующие
задачи:
◦ уточнение диаграмм ВИС;
◦ выбор подходящей прикладной архитектуры
решения;
◦ создание концептуальной модели решения.
Требования бизнеса делятся не следующие
категории: пользовательские, системные,
процедурные,бизнес-требования.
Чтобы создать концептуальный дизайн решения,
определяют сервисы и архитектуру решения.
Существует несколько видов сервисов,
предоставляемых решением: пользовательские
сервисы, сервисы данных и системные сервисы.
40
Сервис Пример
Пользовательский Сервис отображения
заказа
Системный Сервис размещения
заказа
Данных Сервис информации о
заказе

41. Логический дизайн
Логический дизайн — это процесс описания продукта в терминах организации, структуры,
синтаксиса и взаимодействия его частей с точки зрения проектной команды.
Этап логического дизайна состоит из двух перекрывающихся стадий:
◦ стадии анализа, во время которой определяются бизнес-объекты, сервисы, атрибуты и отношения
между объектами;
◦ стадии оптимизации, во время которой команда уточняет список бизнес-объектов и на основании
их определяет новые объекты и сценарии.
Результаты логического дизайна таковы:
◦ логическая модель компонент— набор компонент и соответствующих им операций, атрибутов и
отношений;
◦ высокоуровневый дизайн пользовательского интерфейса;
◦ логическая модель данных.
41

42. Физический дизайн
Физический дизайн — это процесс описания
компонентов, сервисов и технологий решения
сточки зрения разработчиков (программистов).
Цели физического дизайна:
◦ превратить логический дизайн в
спецификации набора компонентов;
◦ определить технологии, оптимальные для
программирования;
◦ создать структурное представление решения с
точки зрения группы разработчиков.
Физический дизайн дает новые результаты, в том
числе:
◦ диаграммы классов;
◦ диаграммы последовательностей;
◦ базовую модель развертывания;
◦ модель программирования (тактики);
◦ спецификации компонентов.
К базовым результатам стадии исследования
относятся:
◦ существующая топология сети;
◦ существующая топология данных;
◦ существующая топология компонентов;
42

43. Практическое упражнение
Цель игры «Лабиринт» состоит в том, что бы сравнить два подхода к
решению задачи:
1. Водопадный
когда в процессе разработки решения отсутствует обратная связь от
команды.
2. Гибкий
когда задача решается все командой.
Microsoft Word
Document
Microsoft Visio
2003-2010 Drawing