Проблема программного обеспечения сводится к трудностям, с которыми сталкиваются разработчики при координации множества рабочих потоков большого программного проекта.
Унифицированный процесс разработки (RUP) является решением этой проблемы, потому что:
- Предоставляет руководство по организации деятельности команды. Направляет задачи каждого разработчика в отдельности и задачи команды в целом. Определяет артефакты, подлежащие разработке. Предлагает критерии для контроля, измерения продуктов и деятельности проекта.
RUP использует UML для подготовки программных схем и основан на программных компонентах, связанных друг с другом через четко определенные интерфейсы. Его основные особенности заключаются в том, что он ориентирован на сценарии использования, ориентирован на архитектуру, является итеративным и инкрементным. Практически можно разделить работу на более мелкие части или мини-проекты, каждый из которых приводит к увеличению или версии продукта.
Жизненный цикл проекта состоит из четырех этапов: концепция, разработка, строительство и переход. Каждый этап заканчивается этапом, на котором есть набор артефактов (документы, модели, исполняемый код и т. Д.), Его наиболее важной целью является то, чтобы руководители проектов могли принимать решения для перехода к следующему этапу. В конце фаз жизненного цикла версия продукта заканчивается.
На этапе проектирования описание конечного продукта разрабатывается на основе хорошей идеи и предоставляется бизнес-анализ продукта.
На этапе разработки большинство вариантов использования продукта подробно описываются, а архитектура системы разрабатывается. В конце этого этапа директор готов спланировать мероприятия и оценить ресурсы, необходимые для завершения проекта.
На этапе построения продукт создается, архитектура превращается в целостную систему и уже содержит все согласованные варианты использования.
На переходном этапе системные тесты проводятся с небольшим количеством пользователей для выявления дефектов и недостатков. Разработчики исправляют ошибки и предлагают предлагаемые улучшения.
Каждая фаза может иметь несколько итераций, и каждая итерация может включать несколько процессов рабочего процесса.
Группы разработки программного обеспечения, работающие итеративным образом, имеют членов, которые выходят за рамки планирования и достигают набора целей, поставленных для последующих итераций. Техника перекрывающихся итераций может быть полезной, если ее правильно понимать и манипулировать.
Стандартные итерации l1, l2 и l3 происходят последовательно слева направо, последовательно происходя вниз с каждой итерацией (требования, дизайн, код и тест).
Эти итерации могут перекрываться, как показано на следующем графике:
Следующее ниже показывает перекрывающиеся итерации, управляемые техникой временного блока:
Эта пересекающаяся техника итерации имеет следующие риски:
- Увеличивает работу Увеличивает стоимость отмены проекта Снижает боевой дух Влияние на процесс улучшения Дисциплина менталитета Опасность водопада
Чтобы избежать дублирования итераций в проекте, персонал может быть использован по адресу:
- Два проекта. Несколько ролей. Примите ситуацию с потерей времени. Уменьшите размер группы.
Перекрывающиеся итерации могут быть очень полезны, но вы должны иметь строгий контроль, чтобы они не стали обоюдоострым мечом, для этого вы должны следовать этим двум важным правилам:
- Не допускайте перекрывающихся итераций во время построения, если в процессе строительства. Во время построения не разрешайте выходить за пределы итерации.
Библиографические ссылки:
Филипп Крухтен. «Рациональный унифицированный процесс: введение». Эддисон - Уэсли. 2000.
Барри Бём. «Будьте готовы к гибким методам, с осторожностью». Компьютер, с. 64-69, 2002.
