Размещено на http://allbest.ru/

Размещено на http://allbest.ru/

Содержание

• ВВЕДЕНИЕ
• ПРЕДИСТОРИЯ
• ИТЕРАТИВНАЯ РАЗРАБОТКА
• Что такое итерация
• Итеративный подход
• Проблемы, решаемые при помощи итерации
• Продолжительность итерации
• Причины для использования итераций
• Итерции и фазы
• Rational Unified Process (RUP)
• КОНЦЕПЦИИ RUP
• ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ
• дисциплины жизненного цикла IBM Rational Unified Process (RUP)
• ЗАКЛЮЧЕНИЕ
• Список литературы
• ВВЕДЕНИЕ

Многие полагают, что итеративная и инкрементальная разработка (iterative and incremental development, IID) -- явление новое. Однако на самом деле истоки этого метода восходят еще к середине 50-х годов. На протяжении последующих десятилетий в его пользу высказывались выдающиеся теоретики в области технологии программирования; метод находил успешное воплощение во многих проектах.

В период, когда «быстрые» методы разработки получают все более широкое распространение, некоторые считают итеративную, эволюционную и инкрементальную разработку «современным» решением, пришедшим на смену последовательной модели, тогда как корни данного подхода можно проследить в прошлом. Разумеется, это известно исследователям систем разработки программного обеспечения, но, как ни странно, многие и по сей день проявляют на этот счет полную неосведомленность. Многие примеры относятся к 70-м и 80-м годам -- наиболее активным и наименее известным периодам истории IID.

Одно замечание по поводу терминологии. Некоторые люди предпочитают сводить смысл выражения «итеративная разработка» к исправлению уже сделанного. Между тем, в контексте современных методов быстрой разработки этот термин означает нечто иное: не просто пересмотр проделанной работы, но и эволюционное продвижение вперед; в таком значении этот термин используется, по меньшей мере, с 1968 года.

ПРЕДИСТОРИЯ

Самым первым из обнаруженных текстов, специально посвященных описанию итеративной разработки и рекомендующим ее, был датированный 1968 годом доклад Брайана Рэнделла и Ф.В. Зерчера, сотрудников исследовательского центра IBM T.J. Watson Research Center [1]. Позднее М.М. Леман описал эту работу, положительно отозвавшись об инкрементальной разработке в своем составленном в сентябре 1969 года внутреннем докладе руководству IBM, который был посвящен рекомендациям по методике разработки [2]:

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

Еще одно относящееся к 60-м годам упоминание о рассматриваемом предмете вышло из-под пера Роберта Гласса [3]: «Автор полагает, что инкрементальная разработка дает положительный результат; она обеспечивает возможность более тщательного испытания системы и позволяет избежать осложнений, препятствующих ее внедрению и управлению».

В 1987 году в TRW приступили к реализации растянувшегося на четыре года проекта по модернизации информационной системы командного центра Command Center Processing and Display System Replacement с использованием методов IID [4]. Разработчики осуществили шесть жестко ограниченных по времени итераций, каждая из которых заняла порядка шести месяцев. Их подход согласовывался с идеями, которые позднее получили известность под названием Rational Unified Process (в разработку этих идей внес свой вклад и Уокер Ройс), а именно -- предполагал внимание к высоким рискам и базовой архитектуре уже в ходе первых итераций.

ИТЕРАТИВНАЯ РАЗРАБОТКА

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

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

Что такое итерация

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

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

Итеративный подход

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



1 - Деловое моделирование.

2 - Первоначальное планирование.

3 - Планирование.

4 - Требования.

5 - Анализ и проектирование.

6 - Среда управления конфигурациями и изменениями.

7 - Тестирование.

8 - Оценка.

9 - Реализация.

10 - Развертывание.

Проблемы, решаемые при помощи итерации

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

Итак, преимущества итеративного подхода состоят в следующем:

· снижение воздействия серьезных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

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

· акцент усилий на наиболее важные и критичные направления проекта;

· непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

· раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

· более равномерная загрузка участников проекта;

· эффективное использование накопленного опыта;

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

Продолжительность итерации

Обычно итерации имеют продолжительность 4 недели, но некоторые команды работают с короткими итерациями в одну неделю, или с длинными итерациями в шесть недель. Факторы, влияющие на продолжительность итерации приведены в таблице 1.

Таблица 1. Факторы, влияющие на продолжительность итераций.

Факторы, ведущие к уменьшению продолжительности итерации	Факторы, ведущие к увеличению продолжительности итерации
Небольшие команды	Большие команды
Географически сосредоточенные команды	Географически распределенные команды
Сильная система управления конфигурацией	Плохая система управления конфигурацией
Выделенные ресурсы на полный рабочий день	Ресурсы предоставляются на неполный рабочий день или по матричной схеме
Автоматизированное тестирование	Отсутствие автоматизированного тестирования
Интегрированная инструментальная среда	Отсутствие хорошей интегрированной и автоматизированной инструментальной среды
Опытная в области итеративной разработки команда	Неопытная команда в области итеративной разработки
Быстрое принятие решений	Политические и бюрократические препятствия к быстрому принятию решений
Нечеткие требования	Понятные требования
Нечеткая или хрупкая архитектура	Хорошо определенная и стабильная архитектура
Новая или непонятная технология	Хорошо известная технология

ПРИЧИНЫ ДЛЯ ИСПОЛЬЗОВАНИЯ ИТЕРАЦИЙ

Итеративный подход в сравнении с методом "водопада" имеет несколько проверенных преимуществ:

· Больше вероятность того, что вы создадите приложение, отвечающее потребностям пользователя. Если слишком рано начать сбор требований, это часто приводит к неиспользуемым возможностям ПО. Стандиш Груп (Standish Group) провело исследование тысяч проектов по разработки программного обеспечения и обнаружило, что более 45 процентов возможностей никогда не используются, а еще 19 процентов используются редко (см. рисунок 1). Другими словами, обычно более половины усилий разработчиков тратится впустую на неважные возможности. Чтобы избежать этой проблемы, необходимо привлечь в процесс разработки заказчика и использовать итеративный подход, позволяющий в каждой итерации реализовывать и проверять те возможности, которые считаются наиболее важными. Такой подход позволяет не только как можно раньше проводить проверку ключевых возможностей, но добавлять новую функциональность на поздних стадиях проекта.

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

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

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

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

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

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

· Персонал проекта используется лучшим образом. Многие организации соединяют использование методологии "водопада" с конвейером: аналитики отправляют готовые требования проектировщикам, которые отправляют готовый дизайн программистам, которые отправляют компоненты интеграторам, которые отправляют систему тестировщикам. Подобные передачи из рук в руки являются причиной ошибок и взаимонепонимания, и приводят к уменьшению чувства ответственности за конечный продукт. Итеративный процесс поощряет к расширению опыта участников команды, предоставляя им возможность исполнять различные роли, а менеджеру проекта - использовать персонал лучшим образом и устранять проблемы, порождаемые передачей из рук в руки.

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

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

Рисунок 1.

Большая часть реализованной функциональности используется редко или вообще никогда.

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

Итерации и фазы

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

· Исследование -- Имеется ли согласие относительно того, какую проблему мы пытаемся решить?

· Проработка -- Имеется ли согласие относительно общего решения, понимаем ли мы все риски, подходят ли нам затраты и графики?

· Построение -- Имеется ли согласие относительно того, соответствует ли разработанная система потребностям заинтересованных лиц?

· Передача -- Имеется ли согласие относительно того, что мы можем выпустить систему и завершить проект?

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

Rational Unified Process (RUP)

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

1. Начать проект и решать возникающие проблемы по ходу

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

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

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



Но как наиболее полно предотвратить возможные риски и максимально гарантировать конечный успех? Самый простой путь - использовать чужой опыт, сформированный на основе анализа ошибок и достижений в других проектах и воплощенный в виде "лучших практик" ("best practices") в той или иной методологии.

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

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

КОНЦЕПЦИИ RUP

Шесть проверенных временем ключевых концепций IBM Rational Unified Process (RUP) лежат в основе развития инструментов и процессов Rational уже более 10 лет:

· Адаптация процесса под проект

· Управление запросами заинтересованных лиц

· Организация взаимодействия удаленных команд разработчиков

· Итерационный подход к разработке

· Повышение уровня абстрагирования

· Непрерывное повышение качества

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

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

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

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



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

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

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

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

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

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

ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ

Перечисленные концепции реализуются с помощью методологии IBM Rational Unified Process (RUP), архитектуру которой представляет следующий рисунок



На данном рисунке представлены два измерения:

· Горизонтальная ось представляет время и показывает временные аспекты жизненного цикла процесса

· Вертикальная ось представляет дисциплины, которые определяют физическую структуру процесса

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

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

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

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

1. Начало (Inception)

В фазе Начало:

· Формируются видение и границы проекта.

· Создается экономическое обоснование (business case).

· Определяются основные требования, ограничения и ключевая функциональность продукта.

· Создается базовая версия модели прецедентов.

· Оцениваются риски.

При завершении начальной фазы оценивается достижение вехи целей жизненного цикла (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

2. Уточнение (Elaboration)

В фазе уточнение производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

§ Документирование требований (включая детальное описание для большинства прецедентов).

§ Спроектированную, реализованную и оттестированную исполняемую архитектуру.

§ Обновленное экономическое обоснование и более точные оценки сроков и стоимости.

§ Сниженные основные риски.

Успешное выполнение фазы разработки означает достижение вехи архитектуры жизненного цикла (англ. Lifecycle Architecture Milestone).

3. Построение (Construction)

Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

4. Внедрение (Transition)

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

дисциплины жизненного цикла IBM Rational Unified Process (RUP)

Ключевые дисциплины жизненного цикла IBM Rational Unified Process (RUP), которые часто на русском языке называют процессами, хотя это не совсем верно с точки зрения данной методологии, поддерживаемые инструментальными средствами IBM (и/или третьих фирм):

· Бизнес анализ и моделирование (примеры инструментальных средств: IBM Websphere Business Modeler, IBM Rational Software Modeler, IBM Rational Rose)

· Управление требованиями (IBM Rational Requirements Composer, IBM Rational RequisitePro, IBM Rational Software Modeler,IBM Rational Rose)

· Анализ и проектирование (IBM Rational Software Architect, IBM Rational Rose)

· Реализация (IBM Rational Application Developer, IBM Rational Web Developer, IBM Websphere Integration Developer)

· Тестирование (IBM Rational Quality Manager, IBM Rational Functional Tester, IBM Rational Performance Tester, IBM Rational Robot)

· Развертывание (IBM Rational BuildForge)

· Конфигурационное управление и управление изменениями (IBM Rational Team Concert, IBM Rational ClearCase, IBM Rational ClearQuest)

· Управление проектом (IBM Rational Project Conductor, IBM Rational Team Concert, IBM Rational Insight, Microsoft Project, IBM Rational ClearQuest)

· Управление средой

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

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

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

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

Тестирование посвящено оценке качества создаваемого продукта.

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

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

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

Управление средой включает элементы формирования среды разработки информационной системы и поддержки проектной деятельности.

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

ЗАКЛЮЧЕНИЕ

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

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

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

итерация жизненный цикл автоматизация

СПИСОК ЛИТЕРАТУРЫ

[1] B. Randell, F.W. Zurcher, "Iterative Multi-Level Modeling: A Methodology for Computer System Design", Proc. IFIP, IEEE CS Press, 1968.

[2] M.M. Lehman, "The Programming Process", internal IBM report, 1969; reprinted in Program Evolution-Processes of Software Change, Academic Press, 1985.

[3] R. Glass, "Elementary Level Discussion of Compiler/Interpreter Writing", ACM Computing Surveys, Mar. 1969.

[4] W. Royce, Software Project Management, Addison-Wesley, 1998.

Размещено на Allbest.ru