Обзор

На процесс разработки программного обеспечения оказывают влияние следующие факторы:

• Факторы предметной области, например: поддерживаемый бизнес-процесс, пользователи, имеющиеся решения от конкурентов.
• Факторы жизненного цикла, например: период от начала разработки до выхода на рынок, ожидаемый период эксплуатации ПО, число планируемых выпусков продукта.
• Технические факторы: язык программирования, инструменты, использующиеся для разработки, СУБД, инфраструктура для компонентов, существующие системы ПО.
• Организационные факторы.

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

Бизнес-контекст

Бизнес-контекст - контекст, в котором разрабатывается ПО. Существуют различные типы бизнес-контекстов, определяющих содержание адаптации процесса. Примеры:

• Работа по контракту: ПО создается по заданным спецификациям эксклюзивно для одного заказчика.
• Коммерческая разработка: разработчик выходит на рынок со своим ПО.
• Внутренние проекты: разработчик и заказчик входят в состав одной организации.

Есть также множество промежуточных ситуаций, например, когда только часть разработки ведется субподрядчиками, или когда разработка рассредоточена географически. Хорошим индикатором бизнес-контекста является число различных заинтересованных сторон.

Бизнес-контекст определяет уровень формальности, оформления и строгости процесса. Чем больше заинтересованных сторон - покупателей, заказчиков, субподрядчиков, органов управления, и т.д. - тем больше потребность в создании формальных данных, таких как документации, отчетов, прототипов и больших вех.

Трудозатраты на разработку программного обеспечения

Трудозатраты на разработку программного обеспечения описывается определенными показателями, такими как объем кода (число строк), поставляемый объем инструкций (Delivered Source Instructions), баллами функциональной оценки, числом человеко-дней или просто стоимостью.

Трудозатраты на разработку также влияют на уровень формальности, оформления и строгости процесса. Чем больше размер проекта, тем больше команда разработчиков и, независимо от бизнес-контекста, тем более формальными и явными должны быть требования, интерфейсы и индикаторы хода работ. В случае больших проектов коммуникативные проблемы могут усиливаться еще и географическим рассредоточением команды.

Элемент новизны для организации, занимающейся разработкой

Элемент новизны определяется предыдущими работами данной занимающейся разработкой организации и, в частности, является ли данный цикл разработки первым. Прежде всего - это зрелость организации и процесса разработки, ресурсы, которыми она располагает, навыки ее работников, собрание и подготовка команды, приобретение инструментов и других ресурсов.

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

Элемент новизны относится не только к разрабатываемой системе, но и к зрелости организации, выполняющей заказ, т.к. внедрение новых для нее инструментов и методики также влияет на процесс. В частности, внедрение собственно Rational Unified Process (RUP) должно быть тщательно продуманным и поэтапным. Очевидно, что организация проявит некоторую инертность при внедрении нового процесса и при составлении плана внедрения необходимо стремиться сделать переход от прежних методик как можно более плавным.

Тип приложения

Существует множество типов приложений, например: встроенные системы реального времени, распределенные информационные системы, телекоммуникационные системы, системы автоматизированной разработки программ (CASE) и т.д. Процесс разработки зависит от типа приложения, особенно в части требований к защите, производительности интернационализации, использованию памяти и т.д.

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

Предметная область привносит в процесс такие нюансы:

• Методика и инструменты для выполнения определенных задач. Например, генерирование кода для конечных автоматов.
• Процедуры сертификации. Например, для медицинских приборов.
• Соответствие стандартам. Например, для бухучета или телекоммуникационного оборудования.

Тип разработки

Есть несколько типов разработки:

• Работа по контракту: ПО создается для одного заказчика. При выполнении работы по контракту приходится иметь дело с большим числом заинтересованных сторон. Заказчик, или его представители, должны быть в курсе хода работ, что требует большей формальности. Рабочие продукты, с которыми ознакомляется заказчик, должны быть простыми для понимания. Иногда требуется создание вехи, фиксирующей стоимость оставшейся части проекта. В этом случае необходимо добавить новую веху или приспособить одну из существующих. В других случаях может потребоваться адаптировать этапы своего процесса к модели жизненного цикла, используемой заказчиком.
• Коммерческая разработка: разработчик выходит на массовый рынок со своим ПО. При коммерческой разработке в роли заказчика выступает отдел сбыта (или человек, занимающий аналогичную должность) той же самой организации. В коммерческой разработке период от начала разработки до выхода на рынок обычно играет большую роль, чем функциональность, а потребность в формальном контроле практически отпадает.
• Внутренняя разработка: продукт создается для другого отдела той же организации. Может потребоваться адаптация к другому жизненному циклу, если продукт является частью другого проекта, не использующего RUP. Во внутренних проектах описание рабочих продуктов обычно более подробное за счет технической информации, т.к. заказчик и исполнитель равные по положению.
• Экспериментальная разработка: не имеет непосредственной целью разработку конечного продукта. К экспериментальной разработке прибегают для определения того, возможно ли создать продукт при заданных условиях. Вехи экспериментальных проектов отличны от вех обычных проектов.

Текущий процесс разработки

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

Проблемы и их первопричины

Части процесса, на которых будет акцентироваться внимание вначале его реализации, зависят от того, как проблемы будут идентифицированы и как они будут распределены по важности.   Обратите внимание, что если в организации нет устоявшихся правил работы, то идентификация проблем скорей всего не будет иметь смысла. См. Концепции: Реализация процесса в проекте. Вместо этого может потребоваться определить первопричины проблем. Тогда, для решения проблем нужно будет устранить первопричины путем усовершенствования процесса, связанного с ними, а именно внедрением инструментов для автоматизации процесса и ознакомления с ними штата. 

Примеры проблем

Наиболее частые проблемы:

• Неспособность организации выполнять работы большого объема - организация пытается выполнять большие объемы работы экстенсивно.
• Неспособность идентифицирования всех требований.
• Неспособность работать в условиях изменяющихся требований.
• Неспособность управлять требованиями - конечный продукт не соответствует всем требованиям.
• Неспособность корректно оценивать - прогнозы всегда являются слишком оптимистическими.
• Дефектное проектирование - требования выполняются, но системы проектируются плохо. В чем заключаются проблемы проектирования? Просты ли системы в сопровождении и расширении? Имеются ли проблемы с производительностью, эргономичностью интерфейса и т.д.?
• Неспособность создавать качественные продукты - в создаваемых продуктах слишком много дефектов, возможно из-за плохого тестирования, хотя чаще - из-за плохого управления требованиями и проектирования.
• Неприемлемая производительность ПО.
• Низкое качество.
• Одновременная работа над одним участком кода - если распределение задач и конфигурация плохо контролируются, появляется вероятность внесения разными разработчиками конфликтующих изменений, и работа одного из них будет потеряна.
• Позднее обнаружение проблем. 
• Трудности при переходе от вариантов использования к дизайну.

Примеры первопричин

Проблема часто является результатом нарушения чего-то другого. Необходимо определить первопричины проблем. Наиболее частые первопричины проблем:

• Плохое управление требованиями
• Плохое взаимодействие в команде
• Неустойчивость архитектуры
• Непреодолимая сложность
• Необнаруженная противоречивость требований, дизайна и реализации
• Недостаточное тестирование
• Субъективность оценки состояния проекта
• Отложенное снижение рисков из-за водопадной модель разработки
• Неконтролируемое распространение изменений
• Недостаточная автоматизация
• Отсутствие регламентации для пользовательского интерфейса
• Непродуманность перехода от вариантов использования к дизайну

Организационные факторы

Реализация процесса в организации зависит от от таких факторов, как гибкость организации, ее структура, культура организации и управления, компетентность и навыки команды, опыт предыдущих разработок, отношение к нововведениям.

Организационные факторы также влияют на конфигурацию процесса. Например, если ранее в организации использовалось описание процесса разработки ПО, то перейти на RUP будет легче. В противном случае может быть принято решение ограничить область описания процесса. Также можно уделить особое внимание легкости понимания и использования описания процесса, включая в него наиболее ценную информацию.

Если большинство коллектива не знакомо с некоторыми концепциями, облегчить переход помогут хорошо составленные руководства. Например, если меняется язык программирования, то для содействования его изучению составьте качественные руководящие указания по программированию и проектированию.

Отношение к нововведениям

Непринятие работниками организации инициатив, касающихся внедрения новых технологий, процесса или инструментов разработки - главная угроза успешному внедрению RUP. Слишком большой энтузиазм также может быть вредным, т.к. вместо концентрации на работе люди будут концентрироваться на процессе.

Для оценки настроений персонала предложите ответить на следующие вопросы:

• Какие преимущества вы видите в новой технологии? Какие существующие проблемы она решит? Какие проблемы по вашему мнению возможны после внедрения новой технологии?
• Какие преимущества вы видите в новом процессе? Какие существующие проблемы он решит? Какие проблемы по вашему мнению возможны после внедрения нового процесса?
• Какие преимущества вы видите в новом инструментарии? Какие существующие проблемы он решит? Какие проблемы по вашему мнению возможны после перехода на новый инструментария?

Для оценки мотивации персонала ответьте на следующие вопросы:

• Знают ли все сотрудники организации, почему нужны изменения?
• Уведомлены ли сотрудники организации о состоянии дел у конкурентов и как это влияет на бизнес?
• Уведомлены ли сотрудники организации о технологических изменениях в отрасли и как они влияют на бизнес?  

Знаками негативного отношения будут ответы подобные следующим:

• "Новый процесс не поможет и будет только мешать"
• "Новый процесс требует большого числа документов"
• "Внедрение процесса - непосильная задача"

Вот некоторые советы по изменению отношения:

• Мотивируйте людей указав им на имеющиеся проблемы.
• Объясните, что процесс не навязывается. Он должен рассматриваться лишь как "справочная система", к которой обращаются за руководствами, определениями и т.д.
• Объясните, что будут использоваться только небольшие части процесса. Никому не по силам внедрить процесс целиком, и такая задача даже не ставится. Проведите аналогию с книжной полкой - книги с нее берутся только когда нужна информация в них.
• Выполните пилотный проект, который покажет, что новый процесс и инструменты работают. Задействуйте в нем одного или двух скептиков. 

Знаки чрезмерного энтузиазма:

• Люди полностью полагаются на процесс и думают, что он решит все их проблемы.
• RUP - это простое решение или волшебная формула, которая гарантирует успех.
• Команда стремится потратить много времени на настройку процесса без предварительной оценки связанных с ним проблем, требующих решения. 

Вот некоторые советы на этот случай:

• Определите ожидания. Процесс поможет, но проблемы не решатся сами собой. Их должны решить люди.
• Отговорите людей от чрезмерной траты времени на настройку процесса.
• Люди должны концентрироваться на разработке продуктов.

Техническая и управленческая сложность

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

Увеличение размеры системы, периода эксплуатации усложняет управление проектом. Увеличение степени новизны в предметной области, оригинальности решения увеличивает техническую сложность. Оба вида сложности взаимосвязаны - многие большие проекта также технически сложны. Таким образом:

• Увеличение управленческой сложности влечет за собой дополнительные формальности (проверки, вехи и рабочие продукты).
• Увеличение технической сложности влечет за собой введение определенных методик, ролей, инструментов и, как следствие, больше задач.

Системы классифицируются по технической и управленческой сложности