Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование и разработка информационных систем. Учебное пособие для СПО
.pdf
141
– пользователи активно принимают участие при планировании, анализе рисков, разработке, а также при выполнении оценочных действий;
– потенциально большой объем работы по разработке продукта разбивается на небольшие части, в которых сначала реализуются решающие функции с высокой степенью риска. Это позволяет устранить необходимость продолжения работы над проектом (таким образом, в случае необходимости становится возможным прекратить работу над проектом и уменьшаются расходы);
– сочетаются преимущества каскадной и эволюционной
моделей;
– здесь не ставится цель выполнить невозможное — довести конструкцию до совершенства;
– обратная связь по направлению от пользователей к разработчикам выполняется с высокой частотой и на ранних этапах
модели, что обеспечивает создание нужного продукта высокого
качества;
– повышается продуктивность благодаря использованию
пригодных для повторного использования свойств;
– повышается вероятность предсказуемого поведения системы с помощью уточнения поставленных целей;
– можно выполнять частую оценку совокупных затрат, а
уменьшение рисков связано с затратами.
4.6.2. Недостатки спиральной модели
Спиральная модель применяется на практике довольно
редко, поскольку имеет недостатки:
– если проект имеет низкую степень риска или небольшие
размеры, модель может оказаться дорогостоящей. Оценка рисков после прохождения каждой спирали связана с большими затратами, так как она требует высокопрофессиональных знаний;
– модель имеет усложненную структуру, поэтому может
быть затруднено ее применение разработчиками, менеджерами и
заказчиками;
142
– спираль может продолжаться до бесконечности, поскольку каждая ответная реакция заказчика на созданную версию может порождать новый цикл, что затягивает работу;
– большое количество промежуточных стадий может привести к необходимости в обработке внутренней дополнительной
и внешней документации;
– время, затраченное на планирование, повторное определение целей, выполнение анализа рисков и прототипироние, может быть чрезмерным, а сама разработка слишком дорогой;
– при выполнении действий на этапе вне процесса разработки возникает необходимость в переназначении разработчиков;
– отсутствие хорошего средства или метода прототипирования может сделать использование модели неудобным.
4.6.3. Область применения спиральной модели
Спиральную модели целесообразно применять, если существует хотя бы одна из следующих причин:
– в случае больших проектов;
– при разработке новой функции или новой серии продуктов;
– для проектов, выполнение которых сопряжено со средней и высокой степенью риска;
– при разработке систем, требующих большого объема
вычислений, таких, как систем, обеспечивающих принятие решений;
– при выполнении бизнес проектов, а также проектов в области аэрокосмической промышленности, обороны и инжиниринга, где использование спиральной модели уже получило популярность, когда ожидаются существенные изменения, например, при изучении или исследовательской работе;
– когда речь идет о применении новой технологии (например, впервые применяемые объектно-ориентированные принципы) и когда необходимо протестировать базовые концепции;
– когда преимущества разработки невозможно точно
определить, а достижение успеха не гарантировано;
143
– когда организация обладает навыками, требуемыми для
адаптации модели;
– для организаций, которые не могут себе позволить выделить заранее все необходимые для выполнения проекта денежные средства, или в процессе разработки отсутствует финансовая поддержка;
– когда нет смысла браться за выполнение долгосрочного
проекта из-за потенциальных изменений, которые могут произойти в экономических приоритетах;
– когда важно сконцентрировать внимание на неизменяемых или известных частях, причем сбор информации об изменяющихся частях еще не закончен;
– когда пользователи не уверены в своих потребностях
или когда требования слишком сложные.
4.7. Экстремальное программирование
Около 60 % всех программных проектов не используют
традиционные модели разработки. Для небольших по объему
проектов они с успехом подменяются интуицией опытного разработчика, руководящего проектом. Другая крайность — это
проекты, в которых каждый аспект строго контролируется. Разработчики проектов не вольны даже в мелочах, они контролируются внешними организациями. То есть работа программистов потеряла прелесть творчества, ограниченные возможности
самовыражения.
Суммируя это, Кент Бек, Уорд Каннингем, Рон Джеффрис
создали методику ХР (2001 г.). Экстремальное программирование (Extreme Programming — ХР) — на сегодня наиболее прогрессивная форма работы над проектом. Основная цель ХР —
создание высококачественных программ с минимальными затратами и в кратчайшие сроки. Одно из главных особенностей —
отказ от всего, что не поддерживает непосредственно эту цель.
В экстремальном программировании ценится каждый человек: в нем не признается общепринятая философия менеджмента, основанная на том, что люди являются легко заменяемыми компонентами в механизме разработки программного обеспечения. Ключевые понятия ХР — команда, игра. Поддержание
144
непринужденного стиля общения, интереса к разрабатываемому
проекту, командного духа — это тоже основа ХР. При этом достигается ощутимый экономический эффект. Поскольку разработчик, заинтересованный процессом работы и климатом в коллективе, работает более продуктивно.
4.7.1. Основные принципы XP
1. Работайте с заказчиком.
В работе над проектом должен непосредственно участвовать реальный заказчик, один из конечных пользователей системы. Надо представлять потребности и др. пользователей.
Заказчик должен отвечать на вопросы и принимать решения относительно приоритета характеристик системы, рисков и
т.д. Он непосредственно участвует в планировании – пишет ролевые сценарии и расставляет их приоритеты, принимая решения о содержимом очередной версии. Поскольку заказчик работает с командой разработчиков, осуществляется постоянная обратная связь; заказчик отвечает на все вопросы команды, касающиеся разъяснения отдельных историй и уточнения требований. Заказчик должен быть доступен, у него должно быть выделено время на консультации с разработчиками.
Заказчик также отвечает за написание приемочных тестов.
2. Используйте метафоры для описания сложных кон-
цепций.
Метафора — это мощный способ описать сложное поня-
тие из незнакомой области. Метафора может быть упрощенным
представлением какой-то концепции или характерной черты.
Метафоры не задуманы как точные определения. Они, скорее,
предоставляют контекст для обсуждения проблем и их решения.
Метафоры особенно полезны, когда разработчиков из одной области привлекают к проекту из другой области.
3. Планируйте.
Планирование обеспечивает взаимное понимание всеми
участниками приблизительных сроков проекта, соотношение
размеров проекта и возможностей организации (т. е. не является
ли проект большим, чем возможности команды). Необходимо,
145
чтобы у всех участников проекта было общее понимание и
направление работы.
Конечно, планирование не означает, что надо в течение
полугода проводить детальный анализ и разрабатывать понедельный план на следующие пять лет. Тем не менее, необходимо
производить минимальное планирование, чтобы знать задания,
приблизительный срок окончания работы и риски, с которыми
можете столкнуться при выполнении проекта.
Следует понимать, что план неточен, и он будет меняться
с возникновением новых условий, требований и появлением новых рисков. Это объясняется тем, что планировать на дальний
срок очень сложно. К тому времени ваш план может быть уже
кардинальным образом перестроен.
Планирование выполняют люди, компетентные в данном
вопросе. Это означает, что решения, касающиеся бизнеса, принимает заказчик, а команда разработчиков принимает решения в
технических вопросах.
4. Проводите короткие совещания.
Собрания. Зачастую их ненавидят, потому что они длинные, затянутые и скучные. Тем не менее, собрания бесценны в
форме живых обсуждений, коротких и содержательных. С этой
целью в экстремальном программировании проводятся собрания
«стоя», основанные на одной простой концепции: никаких стульев. Если все должны во время собрания стоять, то оно, без сомнения, будет коротким и содержательным.
Каждый участник команды подводит краткий итог на сегодняшний день: какие задачи были выполнены вчера, какими
они будут сегодня, о каких важных вопросах или новостях
должна узнать команда.
Пусть смысл беседы будет емким. Не позволяйте начинать
какие-либо дискуссии. Если людям необходимо поговорить, они
могут встретиться позже в течение дня.
5. Сначала пишите тесты.
Тестирование — это еще один важный элемент философии
экстремального программирования. Тестирование происходит
на нескольких уровнях. Первый уровень — это тесты модуле.
Тесты модулей пишутся до того, как будет создана тестируемая
программа. Т.е. порядок действий: тест, затем программа, тест,
146
программа и т.д. Задание нельзя считать завершенным, если для
него не пройден полный набор тестов модулей. Нельзя интегрировать модуль в общую систему, пока не пройдены все его тесты. При интеграции тесты нового модуля добавляются в тестовый набор системы.
Когда и как часто необходимо тестировать? Тестировать
надо как можно чаще, следовательно, тестирования должны
быть быстрыми и легкими. В идеале, надо запускать тесты после
каждой удачной компиляции. В крайнем случае, тесты нужно
выполнять (лучше весь набор тестов). До и после того, как вы
вносите какие-либо изменения.
6. Упрощайте.
Делaйтe все просто — это слова, с которыми мы живем,
это также принцип, на котором основываются при проектировании. Экстремальное программирование стремится проектировать систему как можно проще:
– проектировать на сегодняшний день;
– достигать желаемого как можно более простыми способами;
– постоянно упрощайте дизайн.
Если дизайн простой и в нем нет излишеств, он остается
гибким и адаптируемым. Пренебрегая дизайном, пока он не требуется в системе, можно вместо этого заняться какой-то полезной работой. Это противоречит общепринятому мнению, что
дизайн должен соответствовать не только назревшим, но и будущим требованиям. Ведь есть вероятность, что будущие требования так и не понадобятся.
7. Программируйте в паре.
В ХР код пишется в парах. Каждая строка кода пишется
парой разработчиков. Один работает за клавиатурой, а другой
наблюдает и помогает ему, он помнит о стратегических целях;
вылавливает ошибки; выдвигает свои идеи, замыслы, предложения. Ему проще видеть тот лес, который за деревьями не видит
его товарищ. Далее они меняются местами.
8. Программируйте согласно стандартам.
Все члены команды добровольно придерживаться стандартов. Не имеет значения, каковы они, если они применяются
147
постоянно. Как правило, лучше всего использовать общепринятые стандарты.
9. Коллективное владение кодом.
В традиционной разработке у кода определенного класса
есть «хозяин». При этом все, кому нужно сделать изменения в
«чужом» классе, должны запросить разрешение на изменение у
владельца, то есть приходится ждать, пока у владельца не появится время, чтобы заняться этим вопросом. К тому же это
предполагает узкую специализацию в команде разработчиков. А
это оборачивается крупными неприятностями, если кто-то из
разработчиков увольняется.
Этих неприятностей можно избежать при коллективном
владении кодом. Чтобы система коллективного владения работала, необходима хорошая система контроля проекта, изменяется и механизм управления конфигурацией, нужно постоянно интегрировать систему. Тогда, если возникают конфликты, они
будут небольшими и обнаружатся очень скоро (помните, что
интеграцию необходимо выполнять, как минимум, ежедневно).
10. Постоянно интегрируйте систему.
Постоянно интегрируйте вашу работу в общую программную базу. Интеграция проводится ежедневно, а в идеале — и
чаще. Рекомендуется интегрировать программу после завершения каждого задания. Тесты позволяют с уверенностью принять
решение (в случае, если вся система успешно прошла тестирование) о выпуске новой версии программы. Часто, интегрируя систему, сводятся к минимуму шансы на конфликт ваших изменений с чьими-то другими. Если противоречие все же возникнет,
оно будет минимальным. Эти короткие периоды интегрирования
также обеспечивают общую сходимость. У системы нет времени
на отклонения между интеграциями.
11. Проводите переработку.
Что такое переработка (рефакторинг)? Мартин Фаулер
[Fowler 1999] описывает ее так: надо все время изменять систему:
– при написании тестов для упрощения тестирования какого-то компонента;
– при кодировании некоторых функций для добавления в
систему этой возможности или для исключения дублирования;
– для преобразования существующего кода в шаблон.
148
12. Чаще выпускайте версии.
Новая версия — это ощутимый и работающий результат
работы — вот идея выпуска небольших версий. Работа над небольшой версией длится от одного до нескольких месяцев. Как
правило, полгода уже слишком большой срок. Небольшими версиями пользователям передаются новые функции настолько рано, насколько это возможно, тем самым передавая важную информацию от заказчика, к тому же небольшие частые версии
способствуют наиболее раннему выявлению возможных недостатков. Считается, что новая версия должна выпускаться каждые 2 месяца.
Частые версии программы также помогают в процессе более точного планирования. Чем дальше находится момент планирования, тем меньше будет точность. Планирование на 2–
3 месяца вперед имеет гораздо больший смысл, чем планирование на полгода или на год вперед.
Однако одно из главных правил ХР гласит: если компонент системы полностью не готов, он не подлежит выпуску.
13. Не перерабатывайте (40-часовая рабочая неделя).
Ни один работник не будет выполнять поставленную задачу хорошо под давлением, в условиях стресса или чрезмерной
усталости. Предотвратить это достаточно просто. Рабочий день
должен быть не более 8 часов — 40-часовая неделя и 8-часовой
день — это схема. Идея состоит в том, чтобы не работать больше, чем работается.
14. Приветствуйте изменения требований.
Изменения требований — это обычное условие быстро
развивающейся среды, в которой мы работаем. Если адаптироваться, то изменения приносят выгоду и наносят удар по конкурентам. Если изменения приветствуются, то это работает на
наше преимущество. Ключевая концепция успешного ХРпроекта — помочь заказчику и команде разработчиков понять,
что изменения являются нормой.
149
4.7.2. Две команды
Одно из многих отличий между экстремальным программированием и традиционным — это понятие команд.
В ХР изменились условия. Традиционно участники проекта имеют узкую специализацию: менеджеры, аналитики, архитекторы, разработчики, группы контроля качества, тестировщики, и т. д. Идея в том, что каждый вносит в проект некоторый
набор навыков. Вместо этого ХР предполагает, что каждый разработчик — важный участник проекта и его постоянное внимание необходимо, а обращение к его навыкам становится правилом.
В экстремальном программировании игроки делятся на
две честно работающие команды: заказчики и разработчики. Заказчики принимают решения относительно:
– области действия. Что должна делать система?
– приоритетов. Какие задания более важны? Когда область действия оказывается слишком большой, какие задачи
нужно убрать или отложить?
– содержимого версий. Что должна вмещать каждая версия?
– даты выпуска версий. Когда выпускаются версии? Этот
вопрос может зависеть от маркетинговой политики.
Разработчики должны решать вопросы:
– оценки сроков. Сколько времени понадобится на выполнение задач?
– результаты. Каковы последствия принятия того или
иного решения? Это технические результаты определенных решений, например, выбранных инструментов, аппаратного обеспечения, компонентов системы и т. д.;
– процесс. Каким образом будет создана система? Сюда
входит организация команды, культура, возможности и т. д.;
– подробный график. Когда будет выполнено задание?
Этот вопрос поможет в составлении графика задач внутри каждой версии. Нередко первыми решаются самые рискованные
проблемы, что минимизирует общий риск при осуществлении
проекта.
150
4.8. Выбор модели жизненного цикла проекта
Итак, существует множество различных моделей или
представлений жизненного цикла разработки ПО. Все они есть
логически построенная последовательность действий, начиная с
определения потребности и заканчивая производством ПО.
Каждая модель состоит из этапов или фаз. Каждая фаза снижает
степень риска при выполнении проекта, поскольку для нее есть
критерии входа и выхода для определения дальнейшего хода
действий. По завершении каждой фазы получают внутренние
или результативные внешние действия.
Каждая модель имеет присущие ей преимущества и недостатки, определяющие ее применение для определенных типов
проектов.
Выбор модели жизненного цикла и ее последующей подгонки можно определить следующим образом:
1. Провести анализ проекта, с помощью ответов на вопро-
сы, содержащихся в специальных таблицах. Характеристики
проекта разделены на четыре категории, а именно:
1) требования;
2) команда разработчиков;
3) коллектив пользователей;
4) тип проекта и риски.
В табл. 4.1 приведен пример категории требований к проекту. Для других категорий составляются аналогичные таблицы.
2. Ответить на вопросы, приведенные для каждой катего-
рии, обведя кружочком слова «да» или «нет».
3. Расположить по степени важности категории и вопросы
внутри категорий, относительно проекта, для которого выбирается приемлемая модель.
4. Сравнить ответы с данными в таблицах для разных мо-
делей жизненного цикла и сделать выбор в пользу модели с максимальным количеством совпадений, учитывая приоритетность
характеристик для конкретного проекта.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]