Адаптация унифицированного процесса
Унифицированный процесс представляет собой обобщенную методологию разработки программного обеспечения любого типа, поэтому в данной лекции представлен конкретный вариант процесса, базирующийся на унифицированном процессе, используемом для разработки программного обеспечения интернет-портала. Этот процесс основывается на личном опыте автора книги, и приводится лишь в качестве варианта унифицированного процесса. Этот процесс можно модифицировать в соответствии с определенными условиями, в зависимости от требований сторон-участников проекта.
В начале работы над любым проектом определяется область, представляющая собой обзор или описание желаемого результата. Если все участники проекта согласны с определенной областью, то далее следует сбор требований, результатом которого является функциональный проект. По завершении сбора требований разрабатывается технический проект, определяющий построение программного решения; результатом является техническая спецификация. Функциональный проект отвечает на вопрос "что", а технический проект – на вопрос "как". После описания решение передается в разработку для реализации построения и тестирования согласно технической спецификации. По завершении процесса разработки программное решение тестируется согласно функциональной спецификации. После прохождения всех необходимых тестов осуществляется публикация программы или ее доставка клиенту, и проект считается завершенным. На рисунке 6.1 показан общий процесс построения веб-сайта.
Рис. 6.1. Общий процесс построения веб-сайта
Многие новые методологии, например, Extreme Programming и Agile, усложняют и расширяют унифицированный процесс. Они предлагают разработчикам возможности по оптимизации процесса создания программного продукта.
Extreme Programming предлагает такие подходы, как исключение документации, уменьшение времени цикла разработки и программирование парами. Элементы Extreme Programming представлены в методологии, обсуждаемой в данной лекции, так как они эффективны при разработке решений для интернета.
Каждый этап имеет промежуточный результат или набор промежуточных результатов, являющихся основанием для дальнейшей работы над проектом. Область обычно является документом, в котором приводятся требования заказчика и оценка разработки решения, отвечающего этим требованиям. В результате сбора требований создается функциональная спецификация, описывающая функционирование программного продукта и его внешний вид. Этап технического проекта заканчивается созданием технической спецификации. В результате разработки и программирования создается группа файлов, которые проходят модульное тестирование, отвечающих требованиям технической спецификации, а также программа инсталляции решения. Итогом этапа тестирования продукта является документ, свидетельствующий о том, что в результате программирования разработано программное решение, отвечающее требованиям функциональной спецификации. Наконец, на этапе реализации выставляется счет, сообщается о выходе программы пользователям и создается инструкция по эксплуатации программного продукта.
Примечание. Примеры документов, описываемых в данной лекции, доступны на веб-сайте автора книги.
Передача промежуточных результатов между этапами и командами разработки в рамках программного проекта часто является причиной разногласий. Успех проекта зависит от эффективности работы сотрудников отдела продаж, рекламы, бизнес-аналитиков и инженеров по программному обеспечению. При появлении разногласий порой бывает очень сложно добиться слаженной работы. Эффективной стратегией обеспечения согласованности действий специалистов является такая организация работы, когда при разработке промежуточных результатов руководствуются исключительно требованиями заказчика. Степень производительности в этом случае напрямую зависит от выполнения требований клиента.
В команде разработки ее сотрудники являются клиентами по отношению к друг другу. Например, если функциональной спецификации не хватает ясности в выражении конечного результата при ее прочтении инженером по программному обеспечению, бизнес-аналитик должен усовершенствовать документ, а не надеяться на самостоятельность этого инженера.
Если установка программного обеспечения осуществляется неправильно, то разработчик программы установки или сценария должен ее откорректировать, чтобы системный персонал смог установить программу без проблем. Таким образом, разработчик является клиентом бизнес-аналитика, а системные инженеры – клиентами разработчика. Ответственность за эффективное использование клиентом промежуточных результатов является единицей измерения профессиональной эффективности команды. Если члены команды разработки уважают и любят разрабатываемый продукт, то эффективность их работы будет высока. Привейте команде разработки проекта дисциплину и чувство ответственности, и успех не будет зависеть от индивидуальных особенностей и уровня каждого специалиста в команде разработки.
Еще одной причиной спорных ситуаций является время, затрачиваемое на создание программного продукта. Как правило, чем дольше работа над проектом, тем больше создается функциональных возможностей и программ. Исходные требования могут со временем измениться, поэтому уменьшение сроков доставки снижает вероятность того, что требования заказчика изменятся. Это также понижает уровень стрессовых ситуаций в команде разработки.
Кто-то поспешит заметить, что требования устанавливаются владельцем, а не командой разработки. Уменьшение времени на разработку программного продукта приведет к успеху только при сужении области разработки или расширении штата разработчиков. Естественно, что требования устанавливаются владельцем, поэтому при "урезке" требуемой функциональности владелец удовлетворен не будет. Наилучший способ решить данную проблему – сузить область, т.е. разбить проект на более мелкие. В данном случае владельцу можно предоставить план работы над проектом. Согласно унифицированному процессу такие мелкие проекты называются итерациями. По завершении работы над всеми итерациями осуществляется реализация готового продукта. Предпочтительно разрабатывать программный продукт с использованием большего числа итераций. Одну большую задачу труднее выполнить, она сопряжена с большим риском, чем решение последовательных мелких задач, приводящих к получению такого же продукта.
