SE highligts#4
Всем привет,
В связи с холодами и включением энергосберегающего режима в моем домашнем ноуте(он просто отказался пускать меня в ОС), выпуск highlights перенесся на среду.
Сегодня будет завершение исследования статей господина Боэма на тему будущего Software Engineering (обещаю постараться избегать этого источника какое-то время в будущем J), а также две статьи от Rational - про новый инструмент - Rational Process Composer и про Rational BUP процесс. Если кому интересно - читайте ниже.
Итак,
что же ожидает нас в будущем по Боэму? В статье, Боэм выделяет 8 очевидных и 2 не очень очевидных тенденции, которые будут определять развитие процессов производства ПО в ближайшие 20 лет (почему именно 20 - не спрашивайте, этого он не объясняет). На самом деле, ничего нового и все эти тенденции заметны были всем, кто хотя бы немного в курсе.
Однако, привести ссылку на эту статью я решил по другой причине: дело в том, что в ней описывается интересная модель проектной команды. Эта модель «A Three-Team Adaptive Process Model» позволяет использовать высокий уровень адаптивности легких методологий с предсказуемостью и управляемым качеством результирующего продукта из итеративной модели. Как это выглядит: одна команда работает с использованием Agile принципов над требованиями для итерации, вторая команда мочит код стандартными методами, третья команда проводит независимое тестирование. Таким образом получается одновремено планировать, писать код и верифицировать.
Безусловно, модель не без изъянов. Организация подобной структуры, сама по себе, нетривиальная задача. И, вооще, можно ли использовать эту идею на практике - большой вопрос, но концепция показалась мне красивой. А вообще, на сколько я понимаю, в некоторых известных мне проектах нечто подобное уже работает.
За подробностями про будущее и описанием трехкомандной модели смотрите статью и книгу «Balancing Agility and Discipline», которой в свободном доступе я, к сожалению, не нашел.
Вторая тема сегодня - Rational Process Composer(RPC). Этот продукт, заменяющий собой Rational Process Workbench (презентацию которого я делал в прошлом октябре), и являющийся при этом большим шагом в сторону того инструмента, о котором мы мечтали.
Все помнят, что RPW - это надстройка над Rational XDE, позволяющая создавать описания процессов разработки ПО, используя при этом возможности наследования контента из RUP и других RUP-совместимых описаний. Новый RPC - это stand-alone продукт, позволяющий значительно более гибко управлять описанием процессов и, более того, экспортировать результаты в Rational Portfolio Manager, позволяющий осуществлять Enactment процесса. Если быстро пробежаться по списку недостатков, которые я обнаружил в процессе августовского изучения RPW (неинтуитивный GUI, хранение HTML содержания отдельно от описания процесса, невозможность enactment, отсутсвие reporting’а по построенному процессуи тп), то получается, что специалисты Rational имели доступ к результатам этого анализа и умудрились исправить большинство из обнаруженных недостатков.
На сколько тул пригоден для реальной работы - сказать без исследования, к сожалению, невозможно, но, как минимум, появился претендент на полноценный process authoring tool. Подробности описания процесса подробно изложены в последнем выпуске Rational E-zine здесь и здесь.
Кстати, помимо RPC вышел еще и Eclipse Process Framework - методология BUP (basic unified process) и набор инструментов для authoring’а, enactment’а и даже assessment’a Agile проектов, ведущихся с использованием продуктов IBM. Все продукты этого framework являются бесплатными и open-source.
В комплекте с дистрибутивом RPC идет также полное описание RUP’a и BUP’а в формате RPC.
Статья с описанием BUP и будет третьей темой на сегодня. Так как, возможно, для большинства существование BUP не новость - буду краток.
Даже если вы видели когда-нибудь как сильно отичается RUP for large projects от RUP for small projects, вам все равно будет сложно представить, что же будет если в несколько раз сократить «маленький» RUP. А получится BUP - процесс для производства ПО в Agile проектах размером от 3 до 6 человек, и длительностью менее полугода: всего 6 дисциплин, 5 ролей, 22 артефакта (только 6 из которых имеют «informal templates»). На всем этом построены стандартные 4 руповские фазы, плюс существует механизм описания итераций.
Вообще, стоит поблагодарить Rational за столь щедрый подарок программирующему сообществу. Все равно, полноценный RUP нужен далеко не всем программирующим коллективам, а промежуточное решение между полным хаосом отсутствия процесса и полной задекларированностью RUP’а раньше отсутствовало в копилке IBM.
Однако можно рассмотреть этот поступок голубого гиганта и с менее альтруистической точки зрения - как все помнят первые версии MSF отличались высоким уровнем лаконичности и только сейчас MSF по детальности приближается к младшей версии решения IBM. Таким образом, возможно, BUP является ответом IBM на растущую популярность MSF и попыткой затащить под свои знамена орды программистов, работающих в легком весе.
Вот и все на эту неделю.
Your feedback is appreciated as usual.
В связи с холодами и включением энергосберегающего режима в моем домашнем ноуте(он просто отказался пускать меня в ОС), выпуск highlights перенесся на среду.
Сегодня будет завершение исследования статей господина Боэма на тему будущего Software Engineering (обещаю постараться избегать этого источника какое-то время в будущем J), а также две статьи от Rational - про новый инструмент - Rational Process Composer и про Rational BUP процесс. Если кому интересно - читайте ниже.
Итак,
что же ожидает нас в будущем по Боэму? В статье, Боэм выделяет 8 очевидных и 2 не очень очевидных тенденции, которые будут определять развитие процессов производства ПО в ближайшие 20 лет (почему именно 20 - не спрашивайте, этого он не объясняет). На самом деле, ничего нового и все эти тенденции заметны были всем, кто хотя бы немного в курсе.
Однако, привести ссылку на эту статью я решил по другой причине: дело в том, что в ней описывается интересная модель проектной команды. Эта модель «A Three-Team Adaptive Process Model» позволяет использовать высокий уровень адаптивности легких методологий с предсказуемостью и управляемым качеством результирующего продукта из итеративной модели. Как это выглядит: одна команда работает с использованием Agile принципов над требованиями для итерации, вторая команда мочит код стандартными методами, третья команда проводит независимое тестирование. Таким образом получается одновремено планировать, писать код и верифицировать.
Безусловно, модель не без изъянов. Организация подобной структуры, сама по себе, нетривиальная задача. И, вооще, можно ли использовать эту идею на практике - большой вопрос, но концепция показалась мне красивой. А вообще, на сколько я понимаю, в некоторых известных мне проектах нечто подобное уже работает.
За подробностями про будущее и описанием трехкомандной модели смотрите статью и книгу «Balancing Agility and Discipline», которой в свободном доступе я, к сожалению, не нашел.
Вторая тема сегодня - Rational Process Composer(RPC). Этот продукт, заменяющий собой Rational Process Workbench (презентацию которого я делал в прошлом октябре), и являющийся при этом большим шагом в сторону того инструмента, о котором мы мечтали.
Все помнят, что RPW - это надстройка над Rational XDE, позволяющая создавать описания процессов разработки ПО, используя при этом возможности наследования контента из RUP и других RUP-совместимых описаний. Новый RPC - это stand-alone продукт, позволяющий значительно более гибко управлять описанием процессов и, более того, экспортировать результаты в Rational Portfolio Manager, позволяющий осуществлять Enactment процесса. Если быстро пробежаться по списку недостатков, которые я обнаружил в процессе августовского изучения RPW (неинтуитивный GUI, хранение HTML содержания отдельно от описания процесса, невозможность enactment, отсутсвие reporting’а по построенному процессуи тп), то получается, что специалисты Rational имели доступ к результатам этого анализа и умудрились исправить большинство из обнаруженных недостатков.
На сколько тул пригоден для реальной работы - сказать без исследования, к сожалению, невозможно, но, как минимум, появился претендент на полноценный process authoring tool. Подробности описания процесса подробно изложены в последнем выпуске Rational E-zine здесь и здесь.
Кстати, помимо RPC вышел еще и Eclipse Process Framework - методология BUP (basic unified process) и набор инструментов для authoring’а, enactment’а и даже assessment’a Agile проектов, ведущихся с использованием продуктов IBM. Все продукты этого framework являются бесплатными и open-source.
В комплекте с дистрибутивом RPC идет также полное описание RUP’a и BUP’а в формате RPC.
Статья с описанием BUP и будет третьей темой на сегодня. Так как, возможно, для большинства существование BUP не новость - буду краток.
Даже если вы видели когда-нибудь как сильно отичается RUP for large projects от RUP for small projects, вам все равно будет сложно представить, что же будет если в несколько раз сократить «маленький» RUP. А получится BUP - процесс для производства ПО в Agile проектах размером от 3 до 6 человек, и длительностью менее полугода: всего 6 дисциплин, 5 ролей, 22 артефакта (только 6 из которых имеют «informal templates»). На всем этом построены стандартные 4 руповские фазы, плюс существует механизм описания итераций.
Вообще, стоит поблагодарить Rational за столь щедрый подарок программирующему сообществу. Все равно, полноценный RUP нужен далеко не всем программирующим коллективам, а промежуточное решение между полным хаосом отсутствия процесса и полной задекларированностью RUP’а раньше отсутствовало в копилке IBM.
Однако можно рассмотреть этот поступок голубого гиганта и с менее альтруистической точки зрения - как все помнят первые версии MSF отличались высоким уровнем лаконичности и только сейчас MSF по детальности приближается к младшей версии решения IBM. Таким образом, возможно, BUP является ответом IBM на растущую популярность MSF и попыткой затащить под свои знамена орды программистов, работающих в легком весе.
Вот и все на эту неделю.
Your feedback is appreciated as usual.