Средства разработки приложений: тенденции развития
Средства управления требованиями
Средства моделирования бизнес-процессов, приложений и данных
Средства разработки приложений
Средства тестирования и оптимизации приложений
Средства управления коллективной работой и контроля версий
Что говорят производители средств разработки
Введение
ще
несколько лет назад наиболее широко применяющимися для создания приложений инструментами
были средства разработки приложений и изредка — средства проектирования данных
и генерации отчетов, а говоря о разработке программного обеспечения, многие
в первую очередь подразумевали процесс программирования. И хотя в этот период
происходило развитие современных методологий разработки приложений, моделирования
и управления требованиями, управления самим процессом разработки, оно далеко
не всегда сопровождалось созданием адекватных инструментов — требования формулировались
в виде документов, диаграммы главным образом иллюстрировали проектную документацию,
расчеты стоимости проектов осуществлялись с помощью электронных таблиц.
Последние три-четыре года характеризовались массовым появлением и применением средств поддержки жизненного цикла приложений, нередко хорошо интегрированных между собой. В это время различные производители средств разработки (главным образом лидеры рынка — Microsoft, IBM, Oracle, Borland, Computer Associates, Sun Microsystems) начали предлагать инструменты для различных этапов жизненного цикла приложений, таких как определение требований, моделирование и проектирование приложений и данных, создание приложений, документирование, тестирование и внедрение. Эти инструменты нашли свое применение в компаниях и отделах разработки, руководители которых стремились избавиться от рутинной работы и автоматизировать некоторые из процессов, связанных с разработкой приложений. В этот же период произошла заметная консолидация рынка, выразившаяся в приобретении лидирующими в этой области компаниями инструментов других фирм с целью обеспечения поддержки всех этапов жизненного цикла, а также рост популярности средств поддержки жизненного цикла приложений с открытым кодом и объема инвестируемых в них средств.
 |
|
Средства разработки сегодня
иже
мы кратко перечислим основные категории средств, которые применяются сегодня
различными участниками проектов, связанных с разработкой приложений.
Средства управления требованиями
Управление требованиями — одна из самых важных составных частей процесса разработки. От полноты и точности формулировки требований заказчика проекта во многом зависит объем работы, которую придется переделывать.
Как правило, требования формулируются просто в виде текстового документа (например, технического задания), однако сегодня все большее распространение получают средства управления требованиями, позволяющие в течение проекта отслеживать состояние работы над требованием, связать требование с реализующими его модулями и с тестами, проверяющими, удовлетворяет ли продукт данному требованию.
Из наиболее часто применяющихся в мире средств управления требованиями следует отметить Rational Requisite Pro (IBM, www.ibm.com), Borland CaliberRM (Borland, www.borland.com) и Telelogic DOORS (Telelogic, www.telelogic.com). Эти продукты обладают теми или иными средствами интеграции с другими инструментами поддержки жизненного цикла приложений и позволяют генерировать различные документы, содержащие требования к продукту (например, техническое задание или его аналоги). Отметим, что указанные категории инструментов применяются, как правило, в компаниях-разработчиках или в отделах разработки, хотя иногда заказчикам предоставляется упрощенный интерфейс для доступа к хранилищу требований (например, с помощью Web-интерфейса).
Средства моделирования бизнес-процессов, приложений и данных
Моделирование и проектирование данных также является достаточно важной частью создания готового продукта и применяется во многих компаниях. Инструменты для поддержки этого этапа жизненного цикла приложений можно условно разделить на средства моделирования бизнес-процессов, средства проектирования данных и средства объектно-ориентированного моделирования, при этом многие компании производят инструменты указанных категорий, интегрирующиеся между собой, либо реализуют функциональность нескольких разнотипных средств моделирования в одном продукте. В последнее время подобные инструменты позволяют на основании модели сгенерировать код (серверный или клиентский) или схему базы данных и обладают средствами синхронизации модели с кодом или со структурой базы данных.
К наиболее известным средствам моделирования и проектирования относятся:
- AllFusion Modelling Suite (Computer Associates, www.cai.com), состоящий из нескольких различных инструментов моделирования;
- Oracle Designer, представляющий собой комплексный инструмент, осуществляющий все перечисленные виды моделирования;
- Sybase PowerDesigner, представляющий собой инструмент, в состав которого входят средства создания моделей и объектно-ориентированного моделирования;
- System Architect (Popkin Software), позволяющий осуществлять проектирование данных и структурное моделирование, а также генерировать код клиентских приложений для ряда средств разработки;
- Visio (Microsoft, www.microsoft.com), представляющий собой универсальное средство моделирования данных и приложений (ориентированное главным образом на СУБД и средства разработки производства самой Microsoft);
- Rational Rose и Rational XDE Professional (IBM) — популярные средства объектно-ориентированного UML-моделирования приложений, обладающие средствами интеграции как с другими инструментами самой IBM, так и со средствами разработки некоторых других производителей;
- Together (Borland) — средство UML-моделирования, обладающее на данный момент наиболее совершенными средствами интеграции с различными средствами разработки как компании Borland, так и других производителей (в частности, Microsoft).
Перечисленные инструменты обычно применяются в компаниях-разработчиках или в отделах разработки и изредка — специалистами по сопровождению продуктов. Заказчики и конечные пользователи, за редким исключением, обычно не имеют дела с указанной категорией продуктов.
Отметим, что основная тенденция развития средств моделирования в настоящее время — это появление средств, осуществляющих их интеграцию между собой и с инструментами поддержки других этапов жизненного цикла приложений.
Средства разработки приложений
Средства разработки приложений подразделяются на средства создания Java/J2EE-приложений, средства создания Windows-приложений, средства создания .NET-приложений, инструменты создания приложений для операционных систем, применяющихся в мобильных устройствах, а также на средства создания приложений для различных версий UNIX/Linux и других платформ.
Из компаний, лидирующих на рынке средств разработки Java-приложений, следует отметить Borland, IBM, Oracle, а к наиболее популярным средствам создания приложений для платформ Windows и Microsoft .NET можно отнести Visual Studio .NET и Borland Delphi. Существует также немало инструментов, относящихся к категории Open Source, в частности предназначенных для расширяемой среды Eclipse, которая в настоящее время активно поддерживается корпорацией IBM.
В последнее время производители средств разработки особое внимание уделяют инструментам повышения производительности труда разработчиков, поддержки коллективной работы, повторному использованию моделей и кода, а также средствам интеграции с инструментами поддержки других этапов жизненного цикла приложений. Данная категория инструментов применяется в компаниях-разработчиках или в отделах разработки, изредка используется специалистами по сопровождению программного обеспечения. За редким исключением, она не применяется ни заказчиками, ни конечными пользователями.
Средства тестирования и оптимизации приложений
На этапе тестирования проверяется, удовлетворяет ли приложение сформулированным к нему требованиям, и в продукт вносятся изменения, устраняющие выявленные при тестировании недостатки.
Из наиболее популярных средств тестирования и оптимизации в первую очередь следует отметить набор средств тестирования компании IBM/Rational, инструмент Borland Optimizeit Profiler, интегрирующийся в различные среды разработки, средства тестирования компаний Compuware (www.compuware.com) и Mercury (www.mercury.com).
Характерной особенностью современных средств тестирования является возможность интеграции их со средствами разработки приложений, средствами управления требованиями и иногда — со средствами управления изменениями, а также появление интегрированных сред управления процессом тестирования. Указанная категория инструментов применяется в компаниях-разработчиках или в отделах разработки, а также в обслуживающих их специализированных тестовых лабораториях.
Средства управления коллективной работой и контроля версий
Средства управления коллективной работой применяются на различных этапах создания приложений и подразделяются на средства управления задачами и проектами, средства контроля версий кода, моделей и документов, средства конфигурационного управления.
Из средств контроля версий наиболее популярными считаются Merant PVCS Version Manager и Microsoft Visual SourceSafe, а из средств управления проектами в первую очередь следует отметить семейство продуктов Microsoft Project. Из средств конфигурационного управления прежде всего нужно назвать Borland StarTeam, а также ряд инструментов компании IBM.
Современные средства управления коллективной работой характеризуются, как правило, наличием централизованного репозитария, хранящего составные части проекта, и средств интеграции с другими инструментами управления жизненным циклом приложений. Применяются они чаще всего в компаниях-разработчиках или в отделах разработки, но нередко к таким инструментам обращаются и заказчики, и специалисты по сопровождению ПО.
|
|
Средства разработки завтра
О новых стратегиях и идеях
Стратегии компаний, лидирующих на рынке средств управления жизненным циклом приложений, таких как Borland, IBM, Microsoft, сейчас во многом сходны. Основная цель стратегий этих компаний — повышение количества успешных проектов, процент которых, по данным многих аналитических компаний, до неприличия низок (статистические данные, цитируемые представителями этих компаний, свидетельствуют о том, что 70% проектов выходит за рамки времени, 66% проектов недостаточно успешны, а 30% проектов прекращаются в процессе выполнения).
Названия стратегий лидеров данного сегмента рынка могут быть разными — Software Delivery Optimization, Software Factory, On Demand Business, однако лежащие в их основе идеи более или менее сходны. Эти идеи (и вытекающие из них задачи) включают преодоление барьеров не только между исполнителями проекта, но и между исполнителями и заказчиками, разработчиками и специалистами по эксплуатации и сопровождению продуктов, создателями продукта и конечными пользователями, подтверждая тем самым уже свершившийся для многих проектов факт вовлечения в процесс разработки не только исполнителей, но и заказчиков, и конечных пользователей, и IT-специалистов, отвечающих за эксплуатацию cозданного ПО.
Еще одна идея всех подобных стратегий заключается в том, что процесс создания программного обеспечения следует рассматривать как бизнес-процесс и, как и любой другой бизнес-процесс, оптимизировать его соответствующим образом, так же как оптимизированы процессы управления производством.
В последние пять лет довольно много внимания уделяется не просто быстрой разработке качественного ПО, но и более глобальному управлению этим процессом. Например, именно сейчас руководителям компаний-разработчиков и отделов разработки ПО приходится принимать решения о прекращении работы над неуспешным проектом, управлять портфелем проектов, распределять ресурсы между проектами, решать связанные с этим финансовые и кадровые проблемы. Поэтому cерьезное внимание уделяется методологиям управления портфелями проектов и принципам принятия решений об их приоритетности.
Что говорят производители средств разработки
О том, что именно представляют собой современные стратегии производителей средств управления жизненным циклом приложений, нам удалось расспросить Дэвида Интерсимона (David Intersimone), вице-президента Borland по связям с разработчиками и главного евангелиста этой компании. Ниже приводится фрагмент данного интервью.
Наталия Елманова: Дэвид, наши читатели будут рады снова встретиться с вами.
Недавно компания Borland объявила о новой стратегии, носящей название Software Delivery Optimization (SDO). В чем заключаются основные идеи и цель этой стратегии?
Дэвид Интерсимон: SDO — это эволюция развития наших технологий и идей. Более двадцати лет назад мы начали свою деятельность с персональных инструментов и повышения производительности труда отдельных разработчиков, затем расширили ее, поставив своей целью повышение эффективности деятельности всей команды разработчиков. Наша нынешняя цель — повысить еще и продуктивность деятельности тех, кто заказывает, применяет и поддерживает разрабатываемое программное обеспечение.
Во-первых, помимо команды разработчиков в проекте участвуют представители бизнеса, лица, ответственные за принятие решений. Они оказывают значительное влияние на разработку ПО, принимая решение о том, что именно разрабатывать. Фактически они вовлечены в разработку, и нередко создаваемое программное обеспечение полностью изменяется в соответствии с их пожеланиями. К тому же все решения, связанные с созданием ПО, принимаются за пределами группы разработки.
Дэвид Интерсимон, вице-президент Borland по связям с разработчиками
Во-вторых, после поставки готового продукта с ним будут иметь дело уже другие люди — например, сотрудники IT-отделов, специалисты по сопровождению рабочих мест пользователей, системных администраторов, специалистов по эксплуатации — то есть те, кто должен поддерживать работоспособность этого программного обеспечения. И лучше вовлечь этих людей в процесс разработки не только на этапе внедрения приложения, а задолго до начала процесса разработки, включив их в процесс планирования и определения требований.
Как минимум, каждая компания занимается оценкой рисков с целью принятия решений о разработке продукта или о заказе разработки ПО для повышения эффективности работы бизнес-пользователей, причем задолго до определения требований к этому ПО. В компании всегда есть люди, рассматривающие требования и пытающиеся понять, что именно они собой представляют, оценивающие стоимость проекта задолго до его осуществления, анализирующие, каким будет результат этого проекта. И их работу нужно сделать более продуктивной.
Наша задача заключается в том, чтобы повысить продуктивность деятельности всех участников данного процесса и получить от них максимальную отдачу, позволить им следить за процессом разработки так же, как руководители проектов контролируют работу архитекторов, программистов, специалистов по тестированию. С этой точки зрения SDO — естественная эволюция включения в процесс разработки большего числа людей.
Традиционный бизнес заключается обычно вовсе не в разработке ПО, но, как и в традиционном бизнесе, разработчики решают, что лучше — создать новое поколение выпускаемого продукта или разработать новый продукт? И, как и в традиционном бизнесе, разработчики могут работать сегодня над одним проектом, завтра — над другим, при этом руководитель проекта должен управлять ресурсами (например, членами команды), а руководителю компании или подразделения нужно успешно управлять всеми ресурсами и портфелем проектов. Иными словами, в процесс разработки ПО реально вовлекается много людей, не являющихся членами команды разработчиков, — заказчиков, пользователей, специалистов по сопровождению, руководителей подразделений.
Н.Е.: Следует ли ожидать выпуска инструментов, предназначенных для этих категорий пользователей?
Д.И.: У нас уже есть комплекс инструментов для различных категорий пользователей. Для архитекторов мы предлагаем средства проектирования, для руководителей проектов — инструменты для оценки проекта на основе требований, а для людей, принимающих бизнес-решения, — средства для просмотра сведений о том, что происходит с проектом и какие его этапы пройдены. Те, кто финансирует проект, могут получить другие сведения, например общий обзор состояния проекта. Если на этапе внедрения приложения понадобится внести в него изменения, то для упрощения взаимодействия бизнес-пользователей с бизнес-аналитиками могут потребоваться инструменты, упрощающие формулировку требований и позволяющие получить для планирования необходимую информацию после появления каждого нового требования и оценить, насколько оно важно. Причем каждый из участников проекта будет иметь доступ к одному и тому же репозитарию со сведениями о проекте.
Чтобы принимать критичные для бизнеса решения, руководители подразделений могут посылать информацию специалистам по маркетингу или менеджерам по продажам. То же самое касается и решений, связанных с изменениями в приложениях или с их разработкой. Чем больше людей будет вовлечено в планирование, тем лучше, а данные, которые нужно предоставить бизнес-пользователям и руководителям, у команды разработчиков уже есть — необходимы лишь дополнительные возможности их получения для представителей бизнеса, вовлеченных в процесс создания ПО.
Естественно, мы будем продолжать предоставлять средства управления требованиями, средства разработки с новыми возможностями, средства моделирования. Причем наши предложения разнообразны: архитекторы работают с моделями, руководителей проектов интересуют средства управления проектами, хотя они могут пожелать взглянуть и на требования, и на отслеживание дефектов с целью лучшего понимания состояния проекта. VIP-менеджеры, такие как руководители отделов разработки, могут захотеть проанализировать портфель проектов компании и понять, что происходит с их бюджетами, какие этапы пройдены. Лицам, финансирующим проект, может потребоваться иная информация о проекте и его результатах. У некоторых бизнес-пользователей может возникнуть необходимость самостоятельно работать с требованиями, поскольку им нужно будет решить, насколько важно то или иное. Данные о проекте должны быть доступны всем участникам, а средства информирования об изменениях в проекте просты в применении. Каждый участник процесса должен иметь доступ к единому репозитарию информации о проекте, чтобы принять то или иное решение, — это действительно важно для успешного бизнеса.
Мы совершенствуем инструменты для всех областей, в которых работаем, то есть продолжаем повышать продуктивность разработчиков, архитекторов и пр. Но при этом теперь мы обслуживаем и других участников проекта — например, менеджера по управлению рисками, задача которого — взглянуть на продукт и понять, можно ли его выпустить и как именно, или IT-специалистов, занимающихся установкой продукта, и т.д. Можно добавить эти роли к традиционному списку: архитектор, разработчик, тестировщик, тем более что нередко они требуют не меньшей квалификации.
Н.Е.: А что вы можете рассказать о конкретных проектах компании Borland по реализации указанной стратегии?
Д.И.: Сейчас мы работаем над тремя проектами. Проект Themis фокусируется на всех ролях и аспектах разработки ПО. Архитекторы могут не вникать в аспекты отладки и не изучать исходный код — для них созданы особые категории инструментов ALM. Свои инструменты есть и для руководителей проектов, разработчиков, тестировщиков. Но менеджер по продажам, который работает с заказчиками и пользователями, также может определять требования.
Мы выделяем такие роли, как «аналитик», «архитектор», «разработчик», «специалист по тестированию», и предоставляем необходимую для них функциональность. Но проект Themis ориентирован и на тех, кто будет эксплуатировать готовый продукт, и на обладателей других ролей.
Цель проекта Hyperion — определить процесс и методологию разработки так, чтобы деятельность разработчиков и бизнес-пользователей была максимально продуктивной, чтобы руководитель проектов мог посмотреть на портфель проектов и оценить риски и при этом эффективно управлять командой, работающей над одним или несколькими проектами одновременно. Некоторые команды уже используют метрики, позволяющие управлять ресурсами, зная функциональные требования к продукту, решать, что создавать, какие проекты должны быть приоритетными, как заменить выбывших или отсутствующих членов команды, как найти исполнителей для приоритетного проекта, что именно попросить у кадровой службы при определении ресурсов проекта. В компании должен быть полный репозитарий знаний о каждом члене команды разработчиков — SDO учитывает и кадровые аспекты.
Третий проект — Prometheus — ориентирован на создание аналога ERP-системы для разработчиков.
Н.Е.: Большое спасибо за интересную беседу. Кажется, новая стратегия действительно может облегчить работу команд разработчиков, поэтому КомпьютерПресс желает вам успехов в ее реализации.
От себя добавлю, что вовлечение в процесс разработки специалистов, не имеющих прямого отношения к команде разработчиков, характерно не только для компании Borland. Так, ожидающийся в 2005 году продукт Microsoft Visual Studio 2005 Team System должен способствовать вовлечению в проект IT-специалистов, отвечающих за сопровождение и эксплуатацию ПО, а также партнеров, совместно с которыми производится разработка. Впрочем, развитие средств разработки, выпускаемых лидерами рынка, в первую очередь отражает современные потребности групп разработчиков, заключающиеся в необходимости в сжатые сроки в рамках отнюдь не бесконечного бюджета удовлетворять все более и более серьезные запросы заказчиков.
|
|
Заключение
овременный
рынок инструментов создания приложений не ограничивается собственно средствами
разработки — во многих случаях они играют в процессе разработки далеко не самую
главную роль. Кроме того, важной характеристикой современного рынка средств
управления жизненным циклом приложений является интеграция этих инструментов
между собой и появление наборов средств, исчерпывающих все или почти все задачи,
связанные с реализацией проектов по разработке приложений.
В ближайшее время следует ожидать появления нового поколения инструментов, ориентированных, во-первых, на вовлечение в процесс разработки заказчиков, специалистов по сопровождению ПО и конечных пользователей, а во-вторых, на повышение эффективности планирования и управления группами и отделами разработки в условиях выполнения многих проектов. В дальнейшем же будут созданы средства управления процессом разработки ПО, сходные со средствами управления другими производственными процессами.
