СОВРЕМЕННЫЕ ПРИНЦИПЫ УПРАВЛЕНИЯ СОЗДАНИЕМ ПО

СОВРЕМЕННЫЕ ПРИНЦИПЫ УПРАВЛЕНИЯ СОЗДАНИЕМ ПО

Сегодняшние принципы управления созданием ПО, описанные в разделе 4.1, развиваются и совершенствуются на базе традиционных методов, однако в них не выделены современные принципы, на которых основывается данная книга. Вот мои первые 10 принципов управления созданием ПО, представленные в том же формате, что и принципы Девиса. (Пять первых, являющихся основными для моего определения итерационного процесса, изображены на рис. 4.1.) Все принципы расположены в порядке своей значимости, а слова, выделенные жирным курсивом, используются в дальнейшем в качестве сокращенного варианта развернутых определений.
1.
Основывайте процесс на упреждающей разработке архитектуры.
Это потребует достижения очевидного баланса между ведущими требованиями, архитектурно значимыми решениями при разработке и планированием жизненного цикла до того, как будут задействованы ресурсы для полномасштабной разработки.
2.
Стройте итерационный процесс жизненного цикла таким образом, чтобы он сталкивался с рисками на ранних этапах. В сегодняшних сложнейших программных системах совершенно невозможно последовательно описать проблему целиком, полностью разработать ее решение, создать ПО, после чего протестировать конечный продукт. Напротив, итерационный процесс улучшает понимание проблемы, повышает эффективность решения и плана действий и способствует взвешенному рассмотрению всех задач разработчика. Основные риски должны быть разрешены на ранних стадиях для того, чтобы повысить предсказуемость и избежать дорогостоящих дефектов и доработок, требующих возврата на более ранние стадии разработки.
3.
Изменяйте методы разработки с тем, чтобы перейти к разработке, основанной на компонентах. Переход от склада ума, ориентированного на строки кода, к складу ума, ориентированному на компоненты, является необходимым для уменьшения количества кода, написанного человеком, и разработок на заказ. Компонент — это связный набор заранее написанных строк кода в исходном или выполняемом формате, для которого описаны интерфейс и поведение.
4.
Создавайте среду для управления изменениями. Динамика итерационного процесса, включающего в себя параллельную работу различных команд над одними и теми же продуктами, влечет за собой необходимость объективного контроля над основными результатами.
5.
Повышайте легкость внесения изменений с помощью инструментария, поддерживающего «круговую» разработку. «Круговая» разработка — это поддержка среды, необходимая для автоматизации и синхронизации рабочей информации в различных форматах (таких, как спецификации требований, проектные модели, исходный код, выполняемый код, тестовые варианты). Без существенной автоматизации учета использования системных ресурсов, управления изменениями, документирования и тестирования трудно вместить итерацию в приемлемые временные рамки, при которых внесение изменений приветствуется, а не избегается. Легкость внесения изменений — необходимая составляющая итерационного процесса, а создание интегрированной среды является критичным.
6.
Представляйте рабочие продукты проектирования в строгой, основанной на моделях нотации. Подход, основанный на моделировании (например, UML), поддерживает развитие семантически богатых графических и текстуальных нотаций для описания проекта. Визуальное моделирование с использованием строгих нотаций и формального, пригодного для машинной обработки языка предоставляет гораздо больше средств достижения цели, чем традиционный подход просмотра и оценки проекта, представленного в виде бумажных документов, человеком.
7.
Обеспечивайте процесс инструментами для объективного контроля за качеством и оценки прогресса. Необходимо включить в процесс оценку прогресса и качества всех промежуточных продуктов в течение всего жизненного цикла. Лучшими механизмами оценки являются хорошо описанные измерения, следующие непосредственно из рабочих продуктов и внедренные во все виды деятельности и команды.
8.
Используйте подход, основанный на демонстрациях, для оценки промежуточных продуктов. Перевод рабочих продуктов, соответствующих текущему состоянию проекта (этими материалами могут быть ранний прототип, базовая архитектура или бета-версия некоторой функциональности), в выполняемую демонстрационную версию с соответствующими сценариями стимулирует раннее осуществление интеграции, более полное осознание компромиссов при разработке и раннее избавление от ошибок в архитектуре.
9.
Планируйте промежуточные версии для различных групп сценариев использования со все возрастающим уровнем детализации. Существенным является то, что процесс управления созданием ПО приводит к ранним и постоянным демонстрациям в рамках функционального контекста системы (отдельных вариантов использования). Эволюция последовательных изменений проекта и его поколений должна быть соразмерна текущему уровню понимания. В этом случае связные сценарии использования оказываются главным механизмом для организации требований, описания содержания итерации, оценки реализаций и организации приемочного тестирования.
10. Организуйте конфигурируемый процесс, который окажется экономически масштабируемым. Никакой конкретный процесс не может быть пригоден для всех разработок ПО. Практический подход предполагает, что необходимо иметь возможность конфигурирования процесса для широкого спектра приложений. Процесс должен гарантировать экономию при больших масштабах и возврат инвестиций за счет использования общего духа самого процесса, широкой автоматизации и общих архитектурных образцов и компонентов.
Таблица 4,1.
Подходы, используемые в современном процессе для решения проблем традиционного подхода
Традиционный процесс: 10 главных рисков
Влияет на
Современный процесс: внутренние особенности, позволяющие избавиться от рисков
1. Поздние поломки и избыточные дефекты/доработки
Качество,.
стоимость,.
сроки
Подход с упреждающей разработкой архитектуры.
Итерационная разработка.
Автоматизированное управление изменениями.
Процесс, противостоящий рискам
2, Увольнение ключевых сотрудников
Качество,.
стоимость,.
сроки
Успешное выполнение первых итераций.
Заслуживающие доверия управление и планирование
3, Неадекватные ресурсы для разработки
Стоимость,.
сроки
Среда как важнейшая составляющая процесса.
Предназначенная специально для производства интегрированная среда.
Продукты разработки, основанные на моделях.
«Круговая» разработка
4. Антагонизм между заинтересованными сторонами
Стоимость,.
сроки
Обзоры, основанные на демонстрациях.
Ориентированные на варианты использования требования/тестирование
5. Технологические проблемы
Стоимость,.
сроки
Подход с упреждающей разработкой архитектуры.
Компонентно-ориентированная разработка
Таблица 4.1. (продолжение).
Подходы, используемые в современном процессе для решения проблем традиционного подхода
Традиционный процесс; 10 главных рисков
Влияет на
Современный процесс: внутренние особенности, позволяющие избавиться от рисков
6. «Ползучее» изменение требований
Стоимость,.
сроки
Итерационная разработка Моделирование вариантов использования Обзоры, основанные на демонстрации
7. Паралич анализа
Сроки
Обзоры, основанные нё демонстрации.
Ориентированные на варианты использования требования/тестирование
8. Ненадлежащая производительность
Качество
Оценка производительности, основанная на демонстрации.
Раннее установление обратной связи между архитектурой и производительностью
9. Чрезмерное внимание рабочим продуктам
Сроки
Оценка, основанная на демонстрации Объективный контроль качества
10. Ненадлежащее функционирование
Качество
Итерационная разработка.
Ранние прототипы, последовательные версии

Популярные статьи

Свежие статьи