12.08.2005/136 Алексей Закис RUP и другие методологии разработки ПО
Как сравниватьКак сравнивать две методологии? Казалось бы, очень простой вопрос. По работам и задачам, на которые разбивается разработка ПО. По стадиям разработки, в которые эти работы группируются, и по тому, что входит в каждую стадию. По разрабатываемым документам и моделям. Но что реально даст такое сравнение? Как можно сравнивать по этим показателям современные методологии, которые, вообще говоря, не регламентируют строго ни то, ни другое, ни третье: И как измерять степень различия? В методологию А входит на три артефакта и на две задачи больше, чем в методологию B? И что? Какой вывод можно из этого сделать? Так что же является теми ключевыми характеристиками, которые позволили бы сказать, что методологии А и В близки между собой, а методология С, напротив, отличается от А очень сильно? Видимо, в настоящее время такими ключевыми характеристиками следует считать, прежде всего, отношение методологии к итеративной разработке и степень формальности в оформлении рабочих материалов и вообще в проведении разработки . Итеративная разработкаЧто представляют собой предложенные для сравнения характеристики? Начнем с итеративной разработки ее отличия от каскадной ("водопада"). Если очень коротко, то каскадные методологии разработки ПО исходят из того, что разработка ПО делится на фазы, каждая из которых характеризуется своим набором работ. В отличие от них итеративный подход разбивает разработку на несколько итераций, в ходе каждой из которых выполняются практически все типы работ, и создается реальная работающая система с все более развитыми функциональными возможностями. При каскадном подходе сначала происходит выявление всех требований к проекту и их анализ. Затем проектная группа приступает к проектированию системы (чаще всего, "сверху вниз", разбив создаваемую систему на подсистемы и далее детализируя их до уровня программных процедур и функций). После этого начинается разработка кода и модульное тестирование. После этого идет сборка и системное тестирование. При итерационном подходе разработка ПО разбивается на относительно короткие итерации. Практически во всех итерациях выполняется и выявление требований, и проектирование, и тестирование. Так, в самой первой итерации еще до выявления всех требований может начаться разработка прототипа, на котором проверяются основные архитектурные решения. По мере детализации требований на отдельные подсистемы или компоненты на последующих итерациях начинается их проектирование и кодирование. Разработанные "начерно" подсистемы и компоненты собираются в единую систему (не дожидаясь завершения разработки всех подсистем) и тут же начинается их системное тестирование. Преимущества подобного подхода описаны в отдельной статье , поэтому здесь мы перечислим их коротко. В ходе разработки всегда выявляются дополнительные требования или изменяются выявленные ранее. Также появляются новые ограничения, связанные с принятыми техническими решениями. В наиболее полной мере их удается учесть именно в итерационной разработке, поскольку именно при таком подходе руководство проекта в полной мере готово к изменениям. Уровень формализмаРазличные методологии различаются не только названиями документов и моделей, которые разрабатываются в ходе проекта. Они различаются тем, насколько формализовано ведется разработка. Что входит в это понятие? Во-первых, количество документов. Во-вторых, степень аккуратности их оформления и формальность процедур рецензирования, одобрения и передачи. Одно дело, скажем, методология XP (см. ниже), в соответствие с которой основная документация по проекту - это хорошо документированный код, а для планирования достаточно использовать карточки с краткими описаниями задач. И другое дело - распределенная разработка, в которой материалы проекта передаются в виде предварительно отрецензированных и утвержденных бумажных документов. Почему так важна степень формализма как характеристика методологии? Дело в том, что она очень сильно влияет на скорость и трудоемкость разработки. Детальная документация, выполненная даже с использованием современных CASE средств, требует много времени и много сил. С другой стороны, отсутствие или недостаточный уровень формализма при выполнении проекта может приводить к несогласованности решений, принимаемых участниками проекта, к непродуктивным затратам ресурсов на переработку кода (для согласования частей программного обеспечения, разрабатываемых различными участниками проекта) и на повторное решение типовых проблем. Также может существенно увеличиваться стоимость последующего сопровождения продукта, поскольку внесение каких-либо изменений в него потребует очень больших усилий. С чем сравниватьС какими методологиями имеет смысл сравнивать RUP? Конечно, с теми, которые наиболее распространены или про которые хотя бы можно прочитать. Видимо, все еще самый распространенный метод - это отсутствие какого-либо сознательно выбранного метода. Разработка ведется так, как сложилось, как привыкли. Конечно, в каждой команде свой подход к разработке, тем не менее, и в них можно выявить некоторые общие черты. Структурные методологии, в частности, основанные на подходах Эдварда Йордона, диаграммах "сущность-отношение" и потоках данных, были первыми активно продвигаемыми в нашей стране методологиями. Хотя они нередко связывались (по крайней мере, у слушателей презентаций) с реализующими их CASE средствами, а не рассматривались как самостоятельные методологии, тем не менее, они оказались достаточно известными, хотя нельзя сказать, что широко используемыми. Тем не менее, сравнение с ними имеет определенный смысл. По крайней мере, оно должно показать, насколько RUP отличается от них. Наибольший интерес в настоящее время, видимо, представляет сравнение с гибкими (Agile) методологиями , которые в последние годы активно развиваются и приобрели определенную популярность. Так называется группа относительно новых методов, развиваемых участниками Agile Manifest - объединения в поддержку гибких методов. Общее число таких методологий достаточно велико. Но не все из них широко известны, и не по всем из них можно найти материалы на русском языке. Поэтому для сравнения были выбраны Экстремальное программирование (XP), Crystal Clear и FDD (Feature Driven Development). Кроме методологий, описывающих что, как и в каком порядке надо делать, есть еще один тип документов, регламентирующих разработку ПО. Это международные и государственные стандарты и другие разработки, направленные на определение требований к процессам разработки. Среди стандартов наибольший интерес для отечественного производителя представляют, конечно, ГОСТы 19-ой и 34-ой серий и ГОСТ 12207 Р ИСО МЭК. А среди других регламентирующих документов наиболее известна модель зрелости процессов разработки ПО CMM, разработанная Software Engineering Institute . Как получитсяУвы, это самая сложная для описания категория. Ибо в нее попадают как судорожные метания новичка, пытающегося любой ценой выполнить свой первый проект, так и вполне зрелые и устоявшиеся методологии, вобравшие в себя многолетний и разнообразный опыт конкретных команд разработчиков и даже описанные во внутренних регламентах. Поскольку люди, способные разработать собственную методологию, как правило, могут сами оценить ее с точки зрения итеративности и формализованности, будем ориентироваться на новичков. Увы, чаще всего это означает, что правил ведения разработки либо нет вообще, либо они разработаны и приняты, но не выполняются. Естественным в таких условиях является крайне низкий уровень формализма разработки. Так что с этим все понятно. А что с использованием итеративного подхода? Увы, как правило, он в таких проектах не используется. Прежде всего, потому, что он бы позволил еще на первых итерациях оценить проект как крайне сомнительный. И требующий срочного вмешательства более высокого руководства для наведения порядка. Ведь в итеративном проекте традиционный ответ программиста, что у него уже все на 90% готово, проходит только до момента завершения первой итерации:
Структурные методологииСтруктурные методы - это группа методологий, разработанных, как правило, еще до широкого распространения объектно-ориентированных языков. Все они предполагают каскадную разработку. Хотя, как выяснилось, еще в той статье, которую часто цитируют как первое изложение каскадного подхода, было сказано, что желательно начинать проект с разработки прототипа . То есть, выполнять, как минимум, две итерации. Тем не менее, основу этих методологий составляет последовательный переход от работы к работе и передача результатов (документов) очередного этапа участникам следующего как основа процесса. Также все эти методологии предполагают достаточно высоко формализованный подход, хотя мысли о разумном количестве документации можно найти и в них. В качестве неочевидного примера, напоминающего заодно, что методологии разработки ПО развивались не только на Западе, можно сказать, что в одной из изданных в нашей стране в начале 80-ых годов книге было написано, что степень формализации задания на программирование должна определяться с учетом того, насколько хорошо сработались Аналитик и Программист. И это при том, что тематика книги предполагала разработку достаточно "критических", как их теперь называют, систем, ошибки в которых ведут к серьезным потерям или даже катастрофам.
Гибкие методологииГибкие методологии базируются на десяти принципах, из которых ниже перечислены те, которые определяют оценку этих методологий по выбранным параметрам:
Таким образом, эти методы явно ориентированы на итеративную разработку ПО и на минимальную формализацию процесса. Впрочем, относительно второго момента необходимо сделать оговорку. Они ориентированы на минимально допустимый для данного проекта уровень формализации. В частности, по крайней мере, одна из методологий, входящих в группу гибких, - Crystal - имеет модификации, предназначенные для выполнения процессов с разным количеством участников и разной критичностью разрабатываемого ПО (критичность ПО определяется возможными последствиями ошибок, которые могут меняться в диапазоне от незначительных финансовых потерь на исправление ошибки до катастрофических). Чтобы дальнейшие сравнения с гибкими методологиями не были беспредметным, приведем краткие описания нескольких из них. eXtreme Programming или XP (экстремальное программирование)Методология XP, разработанная Kent Beck, Ward Cunningham, и Ron Jeffries, на сегодня является наиболее известной из гибких методологий. Иногда само понятие гибкие методологии явно или неявно отождествляют с XP. На русском языке издано уже несколько книг, посвященных этой методологии . XP проповедует коммуникабельность, простоту, обратную связь и отвагу. Она описывается как 12 практик: игра в планирование, короткие релизы, метафоры, простой дизайн, переработки кода (refactoring), разработка "тестами вперед", парное программирование, коллективное владение кодом, 40-часовая рабочая неделя, постоянное присутствие заказчика и стандарты кода. Интерес к XP рос снизу вверх, от разработчиков и тестировщиков, замученных тягостным процессом, документацией, метриками и прочим формализмом. Они не отрицали дисциплину, но не желали бессмысленного соблюдения формальных требований. И искали новые быстрые и гибкие подходы к разработке высококачественных программ. При использовании XP тщательное предварительное проектирование ПО заменяется, с одной стороны, постоянным присутствием в команде заказчика, готового ответить на любой вопрос и оценить любой прототип, а с другой стороны, регулярными переработками кода (так называемый рефакторинг). Основой проектной документации считается тщательно прокомментированный код. Очень большое внимание в методологии уделяется тестированию. Как правило, для каждого нового метода сначала пишется тест, а потом уже разрабатывается собственно код метода до тех пор, пока тест не начнет выполняться успешно. Эти тесты сохраняются в наборах, которые автоматически выполняются после любого изменения кода. Парное программирование и 40-часовая рабочая неделя, хотя и являются, возможно, наиболее известными чертами XP, носят все же вспомогательный характер и способствуют высокой производительности разработчиков и низкому количеству ошибок при разработке. Crystal ClearCrystal - семейство методологий, определяющих необходимую степень формализации процесса разработки в зависимости от количества участников и критичности задач. Уступает XP по производительности, зато максимально проста в использовании. Требует минимальных усилий для внедрения, так как ориентирована на человеческие привычки. Считается, что она описывает тот естественный порядок разработки ПО, который устанавливается в достаточно квалифицированных коллективах, если в них не занимаются целенаправленным внедрением другой методологии. Основные характеристики методологии:
Помимо Crystal Clear в семейство Crystal входит еще несколько методологий, предназначенных для выполнения более крупных или более критических проектов. Они отличаются несколько более жесткими требованиями к объему документации и вспомогательным процедурам, таким как управление изменениями и версиями. Feature Driven DevelopmentФункционально-ориентированная разработка (FDD, Feature Driven Development). На самом деле используемое в FDD понятие функции или свойства (feature) системы достаточно близко к понятию прецедента использования, используемому в RUP. Едва ли не самое существенное отличие - это дополнительное ограничение: "каждая функция должна допускать реализацию не более, чем за две недели". То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций. FDD включает пять процессов, последние два из которых повторяются для каждой функции:
Разработчики в FDD делятся на "хозяев классов" и "главных программистов". Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Для сравнения, в XP нет персонально ответственных за классы или методы. К работе над любым классом может привлекаться любой из участников разработки. Работа над проектом предполагает частые сборки и делится на итерации, каждая из которых предполагает реализацию определенного набора функций.
Общие чертыСписок гибких методологий на сегодня достаточно широк. Тем не менее, описанные выше методологии дают достаточно полное представление обо всем семействе. Практически все гибкие методологии используют итеративный подход, при котором детально планируется только ограниченный объем работ, связанный с выпуском очередного релиза. Практически все гибкие методологии ориентированы на максимально неформальный подход к разработке. Если проблему можно решить в разговоре, то лучше именно так и сделать. Причем оформлять принятое решение в виде бумажного или электронного документа нужно только тогда, когда без этого невозможно обойтись. Также практически все гибкие методологии используют довольно ограниченный набор документов, моделей и работ для описания процесса разработки. Это делает их достаточно простыми (по крайней мере, на первый взгляд) для внедрения. Хотя часто эта простота достигается просто за счет того, что многие, безусловно, необходимые работы вроде управления конфигурациями только упоминаются, а не описываются в методологии. И практически все они не предусматривают тех специфических усилий, которых требует разработка принципиально новой архитектуры системы, например, если команда переходит с клиент - серверной архитектуры на использование интернет технологий. ГОСТыГОСТы, как и описываемые в следующем разделе требования модели CMM, не являются методологиями. Они, как правило, не описывают сами процессы разработки ПО. Но они формулируют определенные требования к процессам, которым в той или иной степени соответствуют различные методологии. Сравнение требований по тем же критериям, по которым мы сравниваем методологии, поможет сразу определиться, какими методологиями стоит пользоваться, если вам нужно выполнить соответствующие требования. В настоящее время в России действуют старые ГОСТы 19-ой и 34-ой серий и более новый ГОСТ Р ИСО МЭК 122207. ГОСТы 19-ой и 34-ой серий жестко ориентированы на каскадный подход к разработке ПО. Разработка в соответствие с этими ГОСТами проводится по этапам. Каждый этап предполагает выполнение строго определенных работ. И завершается выпуском достаточно большого числа весьма формализованных и обширных документов. Таким образом, строгое следование этим стандартам сразу приводит к каскадному подходу и к очень высокой степени формализованности разработки. ГОСТ 12207, в отличие от стандартов 19-ой и 34-ой серий, описывает разработку ПО как набор основных и вспомогательных процессов, которые могут действовать с начала до завершения проекта. Касательно модели жизненного цикла сказано, что она может выбираться исходя из особенностей проекта. Таким образом, он не запрещает явно применение итеративного подхода. Но и не рекомендует его использование. Также мягче ГОСТ 12207 и в части требований к формальности процесса разработки. В нем содержатся только указания на необходимость документирования основных результатов всех процессов, но нет перечней необходимых документов и указаний относительно их содержания. Таким образом, ГОСТ 12207 допускает итеративную и менее формализованную разработку ПО.
Модели зрелости процесса разработки (CMM, CMMI)Помимо государственных стандартов, существует несколько подходов к сертификации процесса разработки. Наиболее известными из них в России являются, по-видимому, CMM и CMMI. CMM (Capability Maturity Model) - модель зрелости процессов создания ПО, которая предназначена для оценки уровня зрелости процесса разработки в конкретной компании. В соответствие с этой моделью есть пять уровней зрелости процесса разработки. Первый уровень соответствует разработке "как получится", когда на каждый проект разработчики идут как на подвиг. Второй уровень соответствует более-менее налаженным процессам, когда можно с достаточной уверенностью надеяться на положительный исход проекта. Третий уровень соответствует наличию разработанных и хорошо описанных процессов, используемых при разработке. Четвертый - активному использованию метрик в процессе управления для постановки целей и контроля их достижения. И, наконец, пятый уровень означает способность компании оптимизировать процесс по мере необходимости. После появления CMM стали разрабатываться специализированные модели зрелости для разработки информационных систем, для процесса выбора поставщиков и некоторые другие. На их основе была разработана интегрированная модель CMMI (Capability Maturity Model Integration). Кроме того, в CMMI была предпринята попытка преодолеть проявившиеся к тому времени недостатки CMM. А именно, преувеличение роли формальных описаний процессов, когда наличие определенной документации оценивалось значительно выше, чем просто хорошо налаженный, но не описанный процесс. Тем не менее, CMMI также ориентирован на использование весьма формализованного процесса. Таким образом, основой CMM и CMMI является формализация процесса разработки. Они нацеливают разработчиков, желающих сертифицироваться на достаточно высокую степень зрелости процесса разработки, на внедрение жесткого формализованного процесса. На максимальных уровнях зрелости предполагается, что этот процесс настраивается для каждого конкретного проекта. Однако, в рамках проекта процесс остается очень жестким. Связь CMM и CMMI с итеративной разработкой более опосредованная. Формально и та, и другая не выдвигают конкретных требований к тому, чтобы придерживаться каскадного или итеративного подхода. Однако, по мнению ряда специалистов, CMM в большей степени совместим с каскадным подходом, в то время как CMMI допускает также и применение итеративного подхода . RUPА теперь вернемся к RUP. Безусловно, RUP - итеративная методология. Хотя выполнение всех фаз или какого-то минимального числа итераций нигде в RUP не оговаривается, весь подход ориентирован на то, что их достаточно много. Только при этом можно настроить процесс для последующих итераций, основываясь на результатах начальных. Ограниченное количество итераций не позволяет использовать в полной мере все преимущества RUP. Вместе с тем, RUP можно использовать и в "практически каскадных" проектах, включающих реально всего пару итераций: одну в фазе Построение и одну в фазе Передача. Кстати говоря, именно такое количество итераций, как правило, реально используется в каскадных проектах. Ведь проведение испытаний и опытной эксплуатации системы предполагает внесение исправлений, которые могут предполагать определенные действия, связанные с анализом, проектированием и разработкой, то есть фактически являются еще одним проходом через все фазы разработки. Что касается формальности методологии, то здесь RUP представляет пользователю весьма широкий диапазон возможностей. Если выполнять все работы и задачи, создавать все артефакты и достаточно формально (то есть с официальным назначением рецензента, с предоставлением рецензентом достаточно полной рецензии в виде электронного или бумажного документа и т.д.) проводить все рецензирования, RUP представляет собой крайне формальную, тяжеловесную методологию. С другой стороны, RUP позволяет разрабатывать только те артефакты и выполнять только те работы и задачи, которые необходимы в конкретном проекте. А выбранные артефакты могут выполняться и рецензироваться с произвольной степенью формальности. Можно требовать детальной проработки и тщательного оформления каждого документа. Можно требовать предоставления столь же тщательно выполненной и оформленной рецензии. И даже по старой практике утверждать каждую такую рецензию на Научно-техническом совете предприятия. А можно ограничиться электронным письмом или наброском на бумаге. В последнее время популярным становится выполнение ряда документов на доске с помощью мела (по старинке) или фломастеров (более новый подход) . А, кроме того, всегда остается еще одна возможность - сформировать документ "в голове". Попросту говоря, продумать соответствующий вопрос, принять соответствующее решение. И, если это решение касается только Вас, то ограничиться, например, комментарием в коде программы. Таким образом, RUP - итеративная методология с очень широким диапазоном возможных решений в части формализации процесса разработки. В отличие от большинства современных методологий или требований к процессу разработки, ориентированных на строго определенный уровень формализации процесса, RUP позволяет использовать в разных проектах различные уровни формализации. А теперь попробуем разобраться с классическим вопросом: "Что такое хорошо и что такое плохо?". А сколько формализма нужно?Долгое время в информационной индустрии бытовало мнение, что чем больше тщательно оформленной документации выпускается в ходе выполнения проекта - тем лучше. Значит, тем тщательнее проработан проект, тем полнее сохраняются и передаются в группу сопровождения знания и проектные решения по проекту и тем проще в дальнейшем сопровождать продукт. Однако оказалось, что это не совсем так. Впрочем, причину проблем сначала, как это нередко бывает, определили не совсем точно. Решили, что вопрос только в объеме документации. Вот, если бы она была компактнее: Почитайте руководства по структурному анализу и проектированию. Сколько там радости по поводу того, что удалось заменить толстые тома компактными диаграммами! И действительно, одна удачная диаграмма может заменить иногда десяток страниц текста. Документация с большим количеством диаграмм стала доступней и компактней. Но и наличие самой лучшей документации не всегда спасает. Разработка идет значительно быстрее, а ошибок совершается значительно меньше, если помимо документации есть человек, который знает, что в ней написано, и может объяснить это всем заинтересованным лицам. Точно так же, как постоянный контакт с заказчиком и возможность быстро получить ответ на любой вопрос ускоряют работу Аналитика, так же возможность обратиться непосредственно к Аналитику и уточнить детали предложенного им решения ускоряет работу Разработчика и далее по цепочке. Кроме того, такие контакты позволяют участникам разработки получить объективную оценку качества предложенных ими решений и накопить весьма полезный профессиональный опыт. И не надо забывать, что разработка и рецензирование документации являются весьма трудоемкими операциями, требующими существенных ресурсов и времени. Таким образом, формальная документация проекта не является единственным каналом передачи информации между участниками разработки и, более того, не является самым быстрым каналом. Использование других каналов и, прежде всего, непосредственного контакта, позволяет существенно ускорить обмен информацией, сократить затраты на разработку документации и вообще ускорить процесс разработки. С другой стороны, увлечение личным общением и пренебрежение формальным документированием и другими формализованными процедурами ведет к потере управляемости проекта. Превышение некоторого объема сведений, которые участники разработки должны хранить в голове, или удлинение периода, в течение которого эти сведения должны там храниться, ведет к очень быстрому росту количества ошибок и, соответственно, затрат на их исправление. К сожалению, не существует единого оптимального уровня формализации процесса. Он должен выбираться каждый раз для каждого конкретного проекта. И может меняться в очень широком диапазоне. Ниже перечислены основные факторы, влияющие на оптимальный уровень формализации процесса. Это:
Таким образом, если ваша организация достаточно велика (больше десятка разработчиков) и если вы выполняете проекты для различных отраслей или для систем различного уровня критичности, вам желательно выбирать для каждого проекта свой оптимальный уровень формализации. И здесь возможности RUP существенно превосходят другие методологии. Он позволяет без переучивания персонала просто за счет выбора используемых в проекте артефактов и способа их разработки и рецензирования получить тот уровень формализма, который нужен. И который гарантирует минимизацию затрат на выполнение проекта и максимально быстрое завершение проекта. Кроме того, с точки зрения обеспечения требуемого уровня формализации разработки, RUP можно использовать, если от вас требуется соблюдение ГОСТов. Он позволяет без труда обеспечить разработку всех необходимых документов (13). Также RUP вполне пригоден, если вы хотите выполнить требования второго и третьего уровня CMM или CMMI. А сколько итераций потребуется?Или, точнее, какой длительности итерации лучше использовать. Вопреки первому предположению, более показательным параметром, чем количество итераций, в данном случае является именно длительность итерации. Начнем с более точного определения итерации. Итерация - это не просто календарный срок, это определенный этап выполнения проекта:
Итерации в процессе разработки позволяют:
С другой стороны, проведение итерации - это определенные дополнительные накладные расходы на подведение итогов и (пере)планирование. Размер этих накладных расходов зависит от числа и распределения участников проекта. Для группы в пять человек, работающей в одной комнате, подведение итогов итерации может занять час времени. Для группы из сотни разработчиков, работающих в нескольких различных городах, на сбор и подведение итогов может уйти пара недель. И еще почти столько же уйдет на доведение новых планов и организацию работы по ним. Так что здесь, как и со степенью формализма, нужно искать оптимум. Продолжительность итерации должна быть тем больше, чем больше и распределеннее команда, и тем меньше, чем больше неопределенность проекта. Например, чем более новая технология используется или чем менее стабильны требования к проекту. Еще одним фактором, влияющим на выбор длительности итерации, является использование инструментальных средств. Так средства управления изменениями и конфигурациями и средства автоматизации тестирования позволяют снизить не только трудоемкость процесса разработки, но и накладные расходы на подведение итогов итерации. В отличие от некоторых других итеративных подходов, RUP не задает жесткие рамки на длительность итерации. На основании опыта собственных разработок, а также собранной статистики IBM Rational рекомендует выбирать продолжительность итерации в диапазоне от одной до восьми недель. Итерации длительностью в 8 недель, как правило, хватает даже для команд численностью порядка ста человек. Можно ли применять RUP, если Заказчик требует строго соответствия ГОСТам 19 и 34? Можно. Для этого, как рекомендуется в уже упоминавшейся статьеОшибка! Закладка не определена., во-первых, нужно постараться полностью использовать возможности "законной" дополнительной итерации, связанной с передачей продукта заказчику. Запланируйте ее такой длинной, насколько это будет возможно. Ну а, кроме того, запланируйте начало работ по разработке и проектированию как можно раньше, а завершение работ по выявлению требований и анализу - как можно позже. После этого никто вам не помешает организовать несколько итераций, не называя их итерациями. Единственная неприятность - придется потратить дополнительное время и ресурсы на формирование более детальной, чем это необходимо, первой версии многих документов и моделей. Впрочем, и этого иногда можно избежать, если договориться с заказчиком, о разработке ПО в несколько этапов. Подведем очередные итогиИтак, подведем итоги второго раздела. RUP - это методология, позволяющая в широком диапазоне выбирать степень формализации и итеративности процесса разработки в зависимости от особенностей проектов и разрабатывающей организации. За счет правильного выбора показателей возможно существенное снижение стоимости и/или сроков разработке при гарантии необходимого качества ПО. С другой стороны, RUP позволяет легко поднять степень формализма разработки, если это нужно, например, для выполнения дополнительных требований заказчика или для успешной сертификации на достаточно высокий уровень CMM. Хорошо освоенный RUP является универсальным процессом, который можно успешно использовать в различных проектах. Для организации достаточно освоить RUP и способы его настройки, чтобы иметь в запасе несколько вариантов процесса разработки для разных типов проектов.
Публикуется с разрешения автора |
