Вариативные проблемы разработки ПО

Участники проекта по разработке программного обеспечения — это все, кто влияет на разработку системы: заказчики (пользователи и владельцы системы) и разработчики (менеджеры проекта, аналитики, проектировщики, программисты и т. д.).

Если рассматривать проблему неудачи проектов со стороны заказчиков, то эти причины выглядят следующим образом:

• • потребности заказчиков не поняты или не полностью зафиксированы;
• • требования заказчиков изменяются слишком часто;
• • заказчики не готовы выделить достаточно ресурсов под проект;
• • заказчики не стремятся к сотрудничеству с разработчиками;
• • ожидания заказчиков нереалистичны.

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

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

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

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

Хорошие разработчики могут дать решение. Высококлассные разработчики могут дать значительно лучшее решение, намного быстрее и дешевле. На згу тему существует довольно известная шутка Брукса: «Великие проекты — удел великих разработчиков» (96|. Мастерство и ответственность разработчиков являются факторами, вклад которых в достижение качества и продуктивности программного обеспечения трудно переоценить.

По мнению известного эксперта в программной индустрии Скотта Амблера, корни проблемы неудачных проектов по вине разработчиков кроются в образовательных и социальных аспектах, которые характерны для всех стран [2].

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

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

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

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

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

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