Разделы презентаций
- Разное
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Rational Unified Process
Содержание
- 1. Rational Unified Process
- 2. Жизненный цикл ПООдним из базовых понятий методологии
- 3. Стандартизация жизненного циклаОсновным нормативным документом, регламентирующим ЖЦ
- 4. Структура жизненного циклаСтруктура ЖЦ ПО по стандарту
- 5. Основной процесс - разработка ПОВсе работы по
- 6. Основной процесс - эксплуатацияРаботы по внедрению компонентов
- 7. Вспомогательный процесс – контроль качестваПроблемы верификации, проверки
- 8. Организационный процесс – управление проектомВопросы планирования и
- 9. Организационный процесс – управление конфигурациейПоддерживает основные процессы
- 10. Каскадная модель жизненного циклаРазбиение всей разработки на
- 11. Каскадная модель жизненного цикла
- 12. Каскадная модель - преимуществана каждом этапе формируется
- 13. Каскадная модель - недостаткипригодна только для таких
- 14. Во что превращается каскадная модель в реальности
- 15. Спиральная модель жизненного циклаДелает упор на начальные
- 16. Спиральная модель жизненного цикла
- 17. Спиральная модель - достоинстваРазработка итерациями отражает объективно
- 18. Спиральная модель - недостаткиОсновной недостаток спирального цикла
- 19. Rational Unified ProcessRational Unified Process (RUP, рациональный
- 20. История RUPИсторически RUP является развитием модели процесса
- 21. «Три кита» RUP1. Весь ход работ направляется
- 22. «Три кита» RUP2. Основным решением, принимаемым в
- 23. «Три кита» RUP3. Основой процесса разработки являются
- 24. Описание требований к программной системе – диаграмма
- 25. Диаграмма вариантов использованияДиаграммы вариантов использования описывают взаимоотношения
- 26. Диаграмма вариантов использования. Условные обозначения
- 27. Диаграмма вариантов использования. Пример
- 28. Правила построения диаграммы При работе с вариантами использования
- 29. Связи между прецедентами в диаграмме вариантов использованияВарианты
- 30. Связи между прецедентами в диаграмме вариантов использования-
- 31. Связи между прецедентами в диаграмме вариантов использования
- 32. Связи между прецедентами в диаграмме вариантов использованияСледует
- 33. Связи между актером и прецедентомОтношение – одно
- 34. Связи между актером и прецедентом
- 35. Связи между актерами – расширение или наследование
- 36. Описание требований к системе дистанционного обученияАктеры: студент,
- 37. Описание требований к системе дистанционного обученияадминистратор: поддержка системы.
- 38. Диаграмма вариантов использования обучающей системы
- 39. РолиНа различных этапах в создание и эксплуатацию
- 40. Примеры ролейбизнес-аналитик;инженер по требованиям;архитектор;проектировщик пользовательского интерфейса;программист-кодировщик;технический писатель;тестировщик;руководитель
- 41. Фазы жизненного циклаRUP выделяет в жизненном цикле
- 42. 1. Фаза начала проекта (Inception)Основная цель этой
- 43. Пример хода работ на фазе начала проекта
- 44. 2. Фаза проектирования (Elaboration) Основная цель этой
- 45. Пример хода работ на фазе проектирования
- 46. 3. Фаза построения (Construction) Основная цель этой
- 47. Пример хода работ на фазе построения
- 48. 4. Фаза внедрения (Transition) Цель этой фазы
- 49. Пример хода работ на фазе внедрения
- 50. Дисциплины RUPДисциплины – это различные наборы деятельностей,
- 51. Дисциплины RUP моделирование предметной области (бизнес-моделирование, Business
- 52. Одиночный проект с использованием RUPRUP можно применять
- 53. Первоначальная идея (вечер субботы)Федя – руководитель команды
- 54. Первоначальная идея (вечер субботы)Вася предложил Феде возможное
- 55. Первоначальная идея (вечер субботы)Поскольку Феде идея понравилась,
- 56. Предложение (утро понедельника)Сегодня во время обеда Васе
- 57. Предложение (утро понедельника)Вася задумался над вопросами:Какую программу
- 58. КонцепцияПроблемаДля организации Феди невозможно собрать согласующиеся данные
- 59. КонцепцияФормулировка концепцииПерсональный таймер (Personal Timer Tool, PTT),
- 60. КонцепцияОсновные участники (актёры)отдельные разработчики;помощник по административной работе;менеджеры проекта.
- 61. КонцепцияВарианты использования (прецеденты)измерение времени для задачи;еженедельное составление
- 62. Концепция
- 63. План
- 64. План. НачалоЯ работаю над этими задачами с
- 65. План. ПроектированиеДумаю, что смогу завершить эту фазу
- 66. План. Проектирование3) у меня станет больше информации
- 67. План. ПостроениеЕсли Федя даст добро на продолжение,
- 68. План. ВыпускЭто будет последний этап, и я
- 69. Список рисков Васизакончилась лицензия на нужные мне
- 70. Экономическое обоснованиеПроект будет занимать 4 часа моего
- 71. Архитектура
- 72. Веха целей жизненного цикла (ЦЖЦ)Феде всё понравилось.
- 73. Концепция и план (этап 2)Я исправил концепцию,
- 74. План (этап 2, окончание)Эти изменения передвинут фазу
- 75. План (модифицированный)
- 76. Список рисков (этап 2)Синхронизация обновления базы данных.Соответствие
- 77. Экономическое обоснование (этап 2)Теперь мы говорим о
- 78. Работаем (вечер понедельника)1. Более подробно разрабатываю 2
- 79. Изображение интерфейса программы
- 80. Работаем (вечер понедельника)3. По мере продвижения появляются
- 81. Поднажмём (вторник)Проблемы с базой данных:1) зависает при
- 82. Веха архитектуры жизненного цикла (АЖЦ)Когда к ужину
- 83. Веха архитектуры жизненного цикла (АЖЦ) – продолжениеВнешний
- 84. Диаграмма вариантов использования (модифицированная)
- 85. Веха архитектуры жизненного цикла (АЖЦ) – окончаниеИтог:
- 86. Больше прогресс, больше изменений (среда)1. Найдено решение
- 87. Почти закончил (четверг)1. Тестирование. Работа с сетью.
- 88. Почти закончил (четверг)4. Опять тестирование.Для начала –
- 89. Бета-версия и выпуск (пятница)1. Утром я отправляюсь
- 90. Бета-версия и выпуск (пятница) - завершение4. Поздно
- 91. 1. Выводы. РискиПрограммиста Васю очень заботят риски:технические
- 92. 2. Выводы. Архитектура и требованияВася начинает проектирование
- 93. 3. Выводы. Процесс измененийВася старается тратить время
- 94. 4. Выводы. ТестированиеПомимо кода продукта, Вася создаёт
- 95. 5. Выводы. Контроль версийЧтобы избежать случайной потери
- 96. 6. Выводы. Руководство пользователяВася пишет простую пользовательскую
- 97. Скачать презентанцию
Жизненный цикл ПООдним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО).ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости
Слайды и текст этой презентации
Слайд 2Жизненный цикл ПО
Одним из базовых понятий методологии проектирования ИС является
понятие жизненного цикла ее программного обеспечения (ЖЦ ПО).
это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Слайд 3Стандартизация жизненного цикла
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный
стандарт ISO/IEC 12207 (ISO - International Organization of Standardization -
Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Слайд 4Структура жизненного цикла
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется
на трех группах процессов:
основные процессы (приобретение, поставка, разработка, эксплуатация,
сопровождение); вспомогательные процессы, которые обеспечивают выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Слайд 5Основной процесс - разработка ПО
Все работы по созданию ПО и
его компонент в соответствии с заданными требованиями, включая оформление проектной
и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т.д.Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование).
Слайд 6Основной процесс - эксплуатация
Работы по внедрению компонентов ПО в эксплуатацию,
в том числе конфигуриро-вание базы данных и рабочих мест пользователей,
обеспечение эксплуатаци-онной документацией, проведение обучения персонала и т.д., и непосред-ственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
Слайд 7Вспомогательный процесс – контроль качества
Проблемы верификации, проверки и тестирования ПО.
Верификация
- это процесс определения того, отвечает ли текущее состояние разработки,
достигнутое на данном этапе, требованиям этого этапа.Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием.
Тестирование связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям.
Слайд 8Организационный процесс – управление проектом
Вопросы планирования и организации работ, создания
коллективов разработчиков и контроля за сроками и качеством выполняемых работ.
Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, обучение персонала и т.п.
Слайд 9Организационный процесс – управление конфигурацией
Поддерживает основные процессы жизненного цикла ПО,
прежде всего процессы разработки и сопровождения ПО.
При создании проектов
сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы.Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.
Слайд 10Каскадная модель жизненного цикла
Разбиение всей разработки на этапы, причем переход
с одного этапа на следующий происходит только после того, как
будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Слайд 12Каскадная модель - преимущества
на каждом этапе формируется законченный набор проектной
документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности
этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Слайд 13Каскадная модель - недостатки
пригодна только для таких проектов, для которых
в самом начале разработки можно достаточно точно и полно сформулировать
все требования ;существенное запаздывание с получением результатов (согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания).
Слайд 15Спиральная модель жизненного цикла
Делает упор на начальные этапы ЖЦ: анализ
и проектирование. На этих этапах реализуемость технических решений проверяется путем
создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Слайд 17Спиральная модель - достоинства
Разработка итерациями отражает объективно существующий спиральный цикл
создания системы.
Неполное завершение работ на каждом этапе позволяет переходить на
следующий этап, не дожидаясь полного завершения работы на текущем.Недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Слайд 18Спиральная модель - недостатки
Основной недостаток спирального цикла – проблема определение
момента перехода на следующий этап.
Для ее решения необходимо ввести временные
ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. 
Слайд 19Rational Unified Process
Rational Unified Process (RUP, рациональный унифицированный процесс) –
это один из вариантов итеративной модели жизненного цикла ПО.
RUP –
это "тяжелый" процесс, детально описанный и предполагающий поддержку собственно разработки исходного кода ПО большим количеством вспомогательных дей-ствий. Это позволяет отделить успешные прак-тики разработки и сопровождения ПО от кон-кретных людей, умеющих их применять, и сде-лать возможным решение задач по конструи-рованию и поддержке сложных систем с помо-щью имеющихся работников, не обязательно являющихся суперпрофессионалами.
Слайд 20История RUP
Исторически RUP является развитием модели процесса разработки, принятой в
компании Ericsson в 70–80-х годах XX века. Эта модель была
создана Джекобсоном (Ivar Jacobson), впоследствии, в 1987 году, основавшим компанию Objectory AB именно для развития технологического процесса разработки ПО как отдельного продукта, который можно было бы переносить в другие организации. После вливания Objectory в Rational в 1995 году разработки Джекобсона были интегрированы с работами Ройса (Walker Royce, сын автора "классической" каскадной модели), Крухтена (Philippe Kruchten) и Буча (Grady Booch), а также с развивавшимся параллельно универсальным языком моделирования (Unified Modeling Language, UML).
Слайд 21«Три кита» RUP
1. Весь ход работ направляется итоговыми целями проекта,
выраженными в виде вариантов использования (use cases) — сценариев взаимодействия
результирующей программной системы с пользователями или другими системами, при выполнении которых пользователи получают значимые для них результаты и услуги. Разработка начинается с выделения вариантов использования и на каждом шаге контролируется степенью приближения к их реализации.
Слайд 22«Три кита» RUP
2. Основным решением, принимаемым в ходе проекта, является
архитектура результирующей программной системы. Архитектура устанавливает набор компонентов, из которых
будет построено ПО, ответственность каждого из компонентов (т.е. решаемые им подзадачи в рамках общих задач системы), четко определяет интерфейсы, через которые они могут взаимодействовать, а также способы взаимодействия компонентов друг с другом.
Слайд 23«Три кита» RUP
3. Основой процесса разработки являются планируемые и управляемые
итерации, объем которых (реализуемая в рамках итерации функциональность и набор
компонентов) определяется на основе архитектуры.
Слайд 24Описание требований к программной системе – диаграмма вариантов использования
Варианты использования
– это методика формирования требований, основанная на сценариях. Этот вид
диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.В самой простой форме в вариантах использования определены действующие лица – актеры и возможные взаимодействия – прецеденты.
Слайд 25Диаграмма вариантов использования
Диаграммы вариантов использования описывают взаимоотношения и зависимости между
группами вариантов использования (прецедентами) и действующих лиц (актерами), участвующими в
процессе.
Слайд 28Правила построения диаграммы
При работе с вариантами использования важно помнить несколько
простых правил:
каждый вариант использования относится как минимум к одному
действующему лицу;каждый вариант использования имеет инициатора;
каждый вариант использования приводит к соответствующему результату.
Слайд 29Связи между прецедентами в диаграмме вариантов использования
Варианты использования также могут
взаимодействовать с другими вариантами использования. Три наиболее часто встречающихся типа
взаимодействия между вариантами использования приведены ниже:- <<включение>> указывает, что вариант использования встраивается в другой вариант использования;
Слайд 30Связи между прецедентами в диаграмме вариантов использования
- () указывает,
что в определённых ситуациях или в некоторой точке (называемой точкой
расширения) вариант использования будет расширен другим;- <<обобщение>> (<<наследование>>) указывает, что вариант использования наследует характеристики «родительского» варианта использования и может переопределить некоторые из них или добавить новые, подобно наследованию в классах.
Слайд 32Связи между прецедентами в диаграмме вариантов использования
Следует подчеркнуть, что потомок
наследует все свойства поведения своего родителя, а также может обладать
дополнительными особенностями поведения.
Слайд 33Связи между актером и прецедентом
Отношение – одно из фундаментальных
понятий в языке UML и в той или иной степени
используется при построении всех графических моделей систем в форме канонических диаграмм.Применительно к диаграммам вариантов использования <<ассоциация>> служит для обозначения специфической роли актера при его взаимодействии с отдельным вариантом использования. Другими словами, <<ассоциация>> специфицирует семантические особенности взаимодействия актеров и вариантов использования в графической модели системы. Других связей между актером и прецедентом быть не может!
Слайд 36Описание требований к системе дистанционного обучения
Актеры: студент, преподаватель, администратор системы,
база данных
Прецеденты:
студент: аутентификация, просмотр лекций, выполнение заданий, тестирование;
преподаватель:
аутентификация, внесение новой информации, составление тестов, просмотр результатов тестирования студентов;
Слайд 39Роли
На различных этапах в создание и эксплуатацию ПО вовлекаются люди,
выполняющие различные роли.
Роль – это абстрактная группа заинтересованных лиц,
участвующих в деятельности по созданию и эксплуатации системы и решающих одни и те же задачи или имеющих одни и те же интересы по отношению к ней.
Слайд 40Примеры ролей
бизнес-аналитик;
инженер по требованиям;
архитектор;
проектировщик пользовательского интерфейса;
программист-кодировщик;
технический писатель;
тестировщик;
руководитель проекта по разработке;
работник
отдела продаж;
конечный пользователь;
администратор системы;
инженер по поддержке
и т.п.
Слайд 41Фазы жизненного цикла
RUP выделяет в жизненном цикле 4 основные фазы,
в рамках каждой из которых возможно проведение нескольких итераций. Кроме
того, разработка системы может пройти через несколько циклов, включающих все 4 фазы.
Слайд 421. Фаза начала проекта (Inception)
Основная цель этой фазы — достичь
компромисса между всеми заинтересованными лицами относительно задач проекта и выделяемых
на него ресурсов.На этой стадии определяются основные цели проекта, руководитель и бюджет, основные средства выполнения — технологии, инструменты, ключевые исполнители. Также, возможно, происходит апробация выбранных технологий, чтобы убедиться в возможности достичь целей с их помощью, и составляются предварительные планы проекта.
На эту фазу может уходить около 10% времени и 5% трудоемкости одного цикла.
Слайд 442. Фаза проектирования (Elaboration)
Основная цель этой фазы — на
базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта,
которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы.На эту фазу может уходить около 30% времени и 20% трудоемкости одного цикла.
Слайд 463. Фаза построения (Construction)
Основная цель этой фазы — детальное
прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной
ранее архитектуры. В результате должна получиться система, реализующая все выделенные варианты использования.На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла.
Слайд 484. Фаза внедрения (Transition)
Цель этой фазы — сделать систему
полностью доступной конечным пользователям. На этой стадии происходит развертывание системы
в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей.На эту фазу может уходить около 10% времени и 10% трудоемкости одного цикла.
Слайд 50Дисциплины RUP
Дисциплины – это различные наборы деятельностей, которые в разных
комбинациях и с разной интенсивностью выполняются на разных фазах.
В документации
по процессу каждая дисциплина сопровождается диаграммой, поясняющей:действия, которые нужно выполнить в ходе работ в рамках данной дисциплины;
артефакты, с которыми надо иметь дело;
и роли вовлеченных в эти действия лиц.
Слайд 51Дисциплины RUP
моделирование предметной области (бизнес-моделирование, Business Modeling);
определение требований
(Requirements);
анализ и проектирование (Analysis and Design);
реализация (Implementation);
тестирование
(Test);развертывание (Deployment);
управление конфигурациями и изменениями (Configuration and Change Management);
управление проектом (Project Management);
управление средой проекта (Environment).
Слайд 52Одиночный проект с использованием RUP
RUP можно применять и к очень
маленьким проектам.
Рассмотрим, как придуманный нами программист Василий Петров в течение
недели выполнил небольшой проект для своего друга Фёдора Иванова.Хотя Петров предпочитает работать один, он сознательно и добросовестно следует чётко определённой технологии.
Слайд 53Первоначальная идея (вечер субботы)
Федя – руководитель команды программистов в небольшой
фирме. У него проблема: необходимо организовать учёт рабочего времени программистов,
затраченного на выполнение каждого типа задач: сбор требований, проектирование, тестирование и администрирование.Каждый программист ведёт учёт своего времени сам (на бумажках, с помощью email и т.п.), а в конце недели все данные объединяются. Это – неудобно. Необходимо стандартизировать и автоматизировать учёт времени.
Слайд 54Первоначальная идея (вечер субботы)
Вася предложил Феде возможное решение проблемы.
Программисты Феди
могут иметь на экране небольшие таймеры, которые они могли бы
активировать, связывать с названием задачи, приостанавливать в период обеденного или другого перерыва, продолжать по окончании перерыва и закрывать по мере выполнения задачи.Эти данные можно хранить в безопасном месте, извлекать и сводить в таблицу в конце недели.
Слайд 55Первоначальная идея (вечер субботы)
Поскольку Феде идея понравилась, то друзья договорились
встретиться в понедельник и более подробно обсудить проект.
Слайд 56Предложение (утро понедельника)
Сегодня во время обеда Васе надо будет придти
к соглашению с Федей по поводу дальнейшего продвижения и получить
от него обязательство на начало выплат по проекту.Надо согласовать с Федей план, концепцию и смету (экономическое обоснование). Если Вася сделает это, то он достигнет первой вехи разработки – вехи Целей Жизненного Цикла (ЦЖЦ).
Слайд 57Предложение (утро понедельника)
Вася задумался над вопросами:
Какую программу я буду создавать?
Сколько ресурсов нужно? Сколько времени это займёт? Какое программное обеспечение
для проекта потребуется? Сколько денег я буду просить у Феди?Для ответов на эти вопросы перед встречей с Федей Вася подготовил следующие документы:
концепцию;
план;
риски:
экономическое обоснование.
Слайд 58Концепция
Проблема
Для организации Феди невозможно собрать согласующиеся данные о затратах времени
на решение различных программистских задач, что препятствует сравнению реального хода
проекта с планом, правильной оплате труда работников и, в конечном счёте, точной оценке трудоёмкости будущих проектов.
Слайд 59Концепция
Формулировка концепции
Персональный таймер (Personal Timer Tool, PTT), измеряющий затраты времени
и сохраняющий эти данные для последующей сортировки и извлечения (в
отличие от произвольно составленных записей и смутных догадок), легко позволит организации Феди проводить систематические, согласованные измерения производимых затрат, прослеживать действительные временные затраты в проекте относительно ожидаемых и лучше проводить работу по оценке объёма работ для будущих проектов.
Слайд 60Концепция
Основные участники (актёры)
отдельные разработчики;
помощник по административной работе;
менеджеры проекта.
Слайд 61Концепция
Варианты использования (прецеденты)
измерение времени для задачи;
еженедельное составление таблиц;
объединение данных по
проекту;
настройка инструмента и базы данных для проекта.
Слайд 64План. Начало
Я работаю над этими задачами с раннего утра и
рассчитываю закончить сразу после бизнес-ланча с Федей. Если я получу
обязательство заплатить за демонстрационный прототип, тогда эта фаза – первый день работы над проектом. Если же Федя не согласится, тогда мы закончим и останемся хорошими друзьями.
Слайд 65План. Проектирование
Думаю, что смогу завершить эту фазу к обеду во
вторник. Я создам черновой прототип, который позволит мне усовершенствовать требования,
решение и план, а также проверить некоторые мои идеи. Потом за обедом мы с Федей обсудим этот прототип.Зачем мне всё это надо:
1) я покажу Феде что-то более конкретное («Я пойму, когда увижу»);
2) я проверю, есть ли у меня на компьютере все нужные инструменты, и не недооцениваю ли я объём работ;
Слайд 66План. Проектирование
3) у меня станет больше информации для создания более
хорошего плана и более подробного графика;
4) я получу отправную точку
для построения чего-то реального с возможностью отбросить всё, что я сделал неправильно;5) я освежу свои навыки в разработке баз данных, а также в программировании на Java.
Я полагаю, что обед во вторник станет важной вехой Архитектуры Жизненного Цикла (АЖЦ). К этому моменту и Федя, и я будем иметь возможность или отказаться от проекта, или существенно переработать его, или спокойно продолжить.
Слайд 67План. Построение
Если Федя даст добро на продолжение, то в среду
утром я начну писать уже не черновой прототип, а реальную
программу чисто и аккуратно, тщательно тестируя её. Потом я попрошу Федю придти ко мне около 14 часов в четверг вместе с одним из своих программистов, чтобы тот попробовал её на своём ноутбуке. Это даст мне ещё полдня на устранение недостатков.Эта операция – веха Начальной Функциональной Готовности (НФГ), поскольку это будет первый раз, когда пользователь будет пробовать программу.
Слайд 68План. Выпуск
Это будет последний этап, и я надеюсь, что он
займёт всего несколько часов. Закончится он релизом, и скорее всего,
я отправлю им программу по email вместе со своим счётом к концу дня в четверг.
Слайд 69Список рисков Васи
закончилась лицензия на нужные мне средства разработки;
база данных
стоит слишком дорого;
механизм обмена между узлами сети в организации Феди
не предусмотрен;машины некоторых программистов Феди не соединены с сетью.
Слайд 70Экономическое обоснование
Проект будет занимать 4 часа моего времени ежедневно.
Может потребоваться
обновление компилятора и базы данных (нужно выяснить).
При моей загруженности и
с небольшим запасом на устранение возможных ошибок это реально.Как убедить Федю: если он сможет освободить полчаса в неделю на одного программиста, плюс два часа на ввод данных и подведение итогов для помощника по админ.работе, то он вернёт свои деньги за 6 месяцев.
Кроме того, я, наверное, смогу продавать эту программу другим по схеме раздела прибыли с Федей.
Слайд 72Веха целей жизненного цикла (ЦЖЦ)
Феде всё понравилось. Однако выясни-лось, что
Вася не полностью понял требования, и необходимо их доработать.
1) Федя
хочет, чтобы все разработчики держали данные в одной базе, доступной через их локальную сеть;2) разработчики не всегда работают на одной и той же машине, особенно когда проводят тестирование.
Проблема! Влияет на архитектуру, требует гораздо больше настроек и тестирования.
Слайд 73Концепция и план (этап 2)
Я исправил концепцию, добавив упомянутое сетевое
свойство.
Веха АЖЦ (конец фазы Проектирова-ние) сдвинута на конец вторника, чтобы
минимизировать риск в архитектуре.Фаза Построение будет выполнена в течение 2 дней за 2 итерации:
1) в среду я протестирую «однополь-зовательскую» версию;
2) в четверг разработаю и протестирую клиент-серверное решение для сети.
Слайд 74План (этап 2, окончание)
Эти изменения передвинут фазу Выпуск – на
пятницу, а выход готового продукта – на вечер пятницы.
Федя также
хочет, чтобы я пришёл к нему в офис в пятницу утром, установил бета-версию и попробовал её там, где она будет работать.
Слайд 76Список рисков (этап 2)
Синхронизация обновления базы данных.
Соответствие задач, проектов и
пользователей на множестве машин.
Политика прав доступа администратора и обычных пользователей.
Один
и тот же пользователь соединяется с двух разных машин. Каковы будут последствия?Диалог у одного из пользователей по какой-то причине «зависает» и блокирует других пользователей.
Слайд 77Экономическое обоснование (этап 2)
Теперь мы говорим о полной рабочей неделе,
поэтому я поднимаю расценки.
Федя окупит свои вложения только за
восемь с половиной месяцев, но он считает разумным заплатить мне 2/5 всей суммы, если я достигну вехи АЖЦ к вечеру вторника.
Слайд 78Работаем (вечер понедельника)
1. Более подробно разрабатываю 2 главных варианта использования:
«Измерение
времени для задачи»;
«Еженедельное составление таблиц».
Определяю для них потоки событий (последовательность
действий, реализуемых при выполнении варианта использования).2. Разрабатываю проект графического интерфейса пользователя.
Слайд 80Работаем (вечер понедельника)
3. По мере продвижения появляются новые вопросы.
Список задач
заранее определён и статичен? (Скорее всего, нет.)
Может ли каждый
разработчик создавать новый список или только использовать имеющийся?Записываю вопросы до выяснения с заказчиком.
4. К утру завершена разработка чернового прототипа программы.
Протестировано всё, что только можно
(в истинном стиле XP).
Слайд 81Поднажмём (вторник)
Проблемы с базой данных:
1) зависает при подключении, поскольку версия
базы данных слишком старая;
2) невнимательно прочитал руководство программиста к этой
базе данных.Построена диаграмма классов, окончательно определяющая архитектуру.
Добавляю ограничения:
код будет работать в Windows XP или Linux;
база данных работает под Windows XP / Windows Server 2003 или выше.
Слайд 82Веха архитектуры жизненного цикла (АЖЦ)
Когда к ужину появился Федя со
своим коллегой Андреем, прототип был завершён. Все данные фиксированы, есть
только один пользователь («Федя») и одна задача («Обдумывание»). Всё готово для демонстрации.Мы погоняли прототип около 5 минут, после чего Андрей его «повесил». Объяс-няю, что надёжность и полнота не являлись целями прототипа, это будет потом.
Слайд 83Веха архитектуры жизненного цикла (АЖЦ) – продолжение
Внешний вид и общие
ощущения от программы, в целом, положительные. Немного реорганизуем интерфейс.
Андрея заботит
проблема потери данных в случае, если кому-то придётся перезагру-жать компьютер в процессе работы счётчика. Добавляю в список требований.Модифицирую концепцию, добавляя новые варианты использования.
Слайд 85Веха архитектуры жизненного цикла (АЖЦ) – окончание
Итог: Федя доволен увиденным
и говорит, что надо продолжать проект. Он не возражает и
против ограничений.
Слайд 86Больше прогресс, больше изменений (среда)
1. Найдено решение проблемы Андрея (сохране-ние
данных при перезагрузке компьютера).
2. Не забываю о контроле версий. После
каждого существенного изменения кода делаю «снимок» всей программы.3. По вариантам использования составляю более полный набор тестов методом эквивалентного разбиения.
4. Днём позвонил Андрей, сообщив, что забыл ещё одно требование: каждый программист может рабо-тать над несколькими задачами сразу, и ему нужно будет несколько активных счётчиков.
Проблема! Изменение концепции. Риск.
Слайд 87Почти закончил (четверг)
1. Тестирование. Работа с сетью. Проблемы.
2. Ещё раз
согласовываю все требования с Федей, пытаясь отказаться от части старых
требований в обмен на добавление новых.Плохая новость: всё-таки придётся реализовывать требование Андрея «один программист – несколько задач».
3. На основе вариантов использования начинаю создавать руководство пользователя.
Слайд 88Почти закончил (четверг)
4. Опять тестирование.
Для начала – нагрузочное тестирование (производительность).
Без проблем.
Пробую обновить БД одновременно с двух машин. Плохо. Нужно
улучшить синхронизацию.5. Поздно ночью проблема решена. Теперь почти всё работает.
Слайд 89Бета-версия и выпуск (пятница)
1. Утром я отправляюсь в компанию Феди
с бета-версией. Устанавливаем базу данных на сервере, программу – на
нескольких машинах программистов, и начинаем всё проверять в реальных условиях.2. На основе проверки фиксирую две ошибки и 12 небольших замечаний.
3. К обеду я возвращаюсь в свой офис. Исправляю все критические ошибки. Игнорирую пока мелкие. Обнаруживаю путём тестирования 4 новых ошибки,
исправляю. Следующий релиз 0.9 готов.
Слайд 90Бета-версия и выпуск (пятница) - завершение
4. Поздно ночью делаю перерыв
для написания комментариев к продукту (Release Notes) и разрабатываю инсталлятор.
К
часу ночи я готов. Проект завершён!
Слайд 911. Выводы. Риски
Программиста Васю очень заботят риски:
технические (технологические, языковые, интерфейсные,
производительность);
деловые (график, накладные расходы, риск невыполнения ожидания).
Для их минимизации Вася
использует итеративный процесс, быстро реализует идеи в целях их проверки и для поддержания связи с заказчиком.Вася составляет план с чётко определёнными сроками, хотя проект будет длиться всего неделю.
Слайд 922. Выводы. Архитектура и требования
Вася начинает проектирование с общей архитектуры,
которую проверяет очень рано. Он проводит более детальное проектирование в
тех областях, в которых решение не столь очевидно.Главное – точно понять, что хочет заказчик (Федя) и сделать так, чтобы заказчик точно понимал, что сделает программист.
Вася не хватается сразу за то, что, как он думает, нужно Феде. Сначала – фиксация требований, свойств и ограничений, затем – их обсуждение с заказчиком, и лишь затем – реализация!
Слайд 933. Выводы. Процесс изменений
Вася старается тратить время на задачи, имеющие
наивысший приоритет (по списку рисков), и следит за тем, чтобы
никакие проблемы не остались «за кадром» и не игнорировались слишком долго.Если с помощью теста выявляется проблема или Федя приходит с новым запросом или идеей, то Вася оформляет это в виде запроса на изменение и переопределяет список рисков и план так, чтобы не выйти из графика.
Слайд 944. Выводы. Тестирование
Помимо кода продукта, Вася создаёт набор функциональных тестов,
соответствующих требованиям (условиям).
Благодаря итеративному процессу тесты совершенствуются так же, как
и код, и становятся всё более исчерпывающими.
Слайд 955. Выводы. Контроль версий
Чтобы избежать случайной потери кода (например, из-за
аварии жёсткого диска или из-за собственной ошибки при совершенствовании программы),
Вася использует простую стратегию управления программой, храня историю версий своих файлов и делая «снимки» версий тестируемых наборов файлов (версия 1 – отдельная папка «MyProgram001», версия 2 – отдельная папка «MyProgram002», ..., завершённый прототип – отдельная папка «MyProgram100»).По этим версиям он следит за развитием программы и вносимыми изменениями, чтобы можно было вернуться к известной конфигурации, если будет допущена ошибка.
Слайд 966. Выводы. Руководство пользователя
Вася пишет простую пользовательскую документацию с:
1) комментариями
к релизу – разделом, описывающим данный релиз, процесс его инсталляции
и известные ограничения;2) руководством пользователя – описанием того, как использовать продукт.
