- Введение
- Этапы, роли, инструменты…
- Определение требований
- Проектирование
- Разработка продукта
- Тестирование и оценка качества
- Документирование
- Внедрение и сопровождение
- Коллективная разработка и управление проектом
- Заключение
Разработка программного обеспечения, как и любая другая сфера деятельности, требует определенного инструментария. Однако если список программного обеспечения, которое обычно нужно среднестатистическому корпоративному пользователю (вариант - среднестатистическому домашнему пользователю), более или менее очевиден, то с разработчиками все обстоит не так просто: список инструментов, применяемых при создании приложений, отнюдь не ограничивается средствами разработки.
Введение
оворя о разработке программного обеспечения, многие пользователи подразумевают в первую очередь написание кода приложений или, в лучшем случае, еще и внедрение созданных продуктов. Подобная точка зрения часто основана на опыте, полученном в прошлом. Многие IT-специалисты и пользователи, особенно старшего возраста, вышли из научной среды. В 80-е годы программирование нередко дополняло научные исследования и, ученый, по существу, сам ставил себе задачу, выполнял ее и был единственным (или одним из немногих) пользователем созданного приложения. Следствием этого стало то, что в начале 90-х годов в России было довольно много разработчиков (зачастую тех самых бывших ученых, умевших программировать), которые создавали уже отчуждаемые продукты, но при этом сами вели переговоры с заказчиками, проектировали приложения, писали код, готовили проектную документацию, тестировали и внедряли продукт, а нередко заодно и сопровождали рабочие станции пользователей. Естественно, набор инструментов такого разработчика-универсала обычно исчерпывался средством разработки, текстовым редактором для подготовки договоров и документации и, намного реже, средствами проектирования данных и генерации дистрибутивов.
Хотя подобных разработчиков-универсалов в России немало и сейчас, но подавляющее большинство компаний, даже относительно небольших, все чаще предпочитают пользоваться услугами узких специалистов. Причиной этого является значительный рост требований к функциональности, дизайну, качеству и удобству применения программного обеспечения (попробуйте предложить современному пользователю текстовый редактор с интерфейсом командной строки вместо Microsoft Word!). Для успешной реализации современных проектов требуется весьма широкий круг знаний и умений, которыми, как правило, обладают разные специалисты, выполняющие в проекте различные операции и нуждающиеся в соответствующих инструментах.
Этапы, роли, инструменты…
овременная методология разработки программного обеспечения предполагает разбиение проекта (или какой-то его части, например очередной итерации проекта) на этапы, на которых специалисты, играющие определенные роли в проекте, выполняют различные действия и производят составные части проекта. Как правило, при любом подходе к организации процесса разработки можно в том или ином виде выделить следующие этапы: бизнес-анализ и определение требований, проектирование, разработка, тестирование и оценка качества, документирование, внедрение и сопровождение - и соответственно такие роли, как руководитель проекта, бизнес-аналитик, системный аналитик, архитектор приложения, автор кода приложения, специалист по тестированию и оценке качества, технический писатель, специалист по внедрению, специалист по сопровождению, специалист по обучению пользователей, специалист по маркетингу созданного продукта. Список ролей может быть расширен в зависимости от масштаба и сложности проекта (например, в некоторых проектах специалисты по тестированию делятся на тест-менеджеров, тест-аналитиков, авторов скриптов для автоматизированного тестирования, специалистов по тестированию пользовательского интерфейса, специалистов по нагрузочному тестированию, и каждому из них требуются свои собственные инструменты), и наоборот - в небольшом проекте один исполнитель может выполнять несколько ролей (например, совмещать роли специалиста по тестированию и технического писателя).
Ниже мы рассмотрим, какие инструменты могут потребоваться команде разработчиков на различных этапах разработки приложения.
Определение требований
Определение требований - это задача бизнес-аналитиков, которые осуществляют предпроектное обследование, общаясь с заказчиком и потенциальными пользователями и выясняя их проблемы и потребности. Результатом обследования обычно является документ, называемый в нашей стране техническим заданием и содержащий сведения о назначении продукта, набор требований к нему и описание границ проекта.
Какие инструменты требуются бизнес-аналитику? Потребность в инструментах определяется масштабом проекта, требованиями заказчика к оформлению документации, стандартами, принятыми в той или иной компании-разработчике. Бизнес-аналитик может обойтись и текстовым процессором (например, Microsoft Word), изложив требования в виде текста. Однако в последнее время описание требований принято иллюстрировать UML- и IDEF0-диаграммами, описывающими сценарии взаимодействия пользователя с продуктом, порядок передачи сообщений от одних объектов к другим, взаимодействие объектов друг с другом, потоки работ и изменение состояний объектов. Для создания таких диаграмм можно применять Microsoft Visio, Rational Rose, Rational XDE, Borland Together, для создания диаграмм в стандарте IDEF0 наиболее активно используется CA AllFusion Process Modeler (ранее носивший название BPwin).
Пример UML-модели (Microsoft Visio)
Какой именно инструмент подходит для данного проекта, во многом зависит от постановки процессов разработки. Если бизнес-аналитику нужно только проиллюстрировать проектную документацию, то выбор инструмента не принципиален - лишь бы можно было нарисовать с его помощью ту или иную диаграмму. Если же бизнес-аналитик должен не просто сделать иллюстрацию, а создать модель для последующего использования системными аналитиками, разработчиками и специалистами по тестированию на последующих этапах проекта, то выбор инструмента определяется его способностью к интеграции со средствами разработки, которые со значительной степенью вероятности будут использоваться в качестве инструментария реализации кода. Из наиболее технологически совершенных современных пар "средство разработки - средство моделирования" стоит отметить такие, как Visual Studio .NET - Rational XDE, Visual Studio .NET - Borland Together, Borland JBuilder - Borland Together.
Помимо текстовых редакторов и средств моделирования, бизнес-аналитики могут применять средства управления требованиями, позволяющие хранить структурированный и систематизированный список требований к продукту в какой-либо базе данных и обращаться к нему на последующих этапах, связывая требования с реализующими их составными частями продукта и тестами, проверяющими соответствие продукта требованиям, а также корректно отслеживать изменения в требованиях, которые возникают практически в каждом проекте, как бы тщательно ни проводилось исследование, и влияние этих изменений на результаты последующей работы. Из наиболее известных сегодня средств управления требованиями следует отметить RequisitePro (IBM/Rational), DOORS (IBM Rational / Telelogic) и CaliberRM (Borland). Собственно, при надлежащей организации процесса разработки и при наличии необходимых шаблонов техническое задание можно сгенерировать с помощью средства управления требованиями и даже соблюсти при этом требования российских государственных стандартов.
Типичный интерфейс средства управления требованиями (Borland Caliber RM)
Таким образом, на этапе определения требований нужны средства подготовки документов, а во многих случаях и средства управления требованиями, моделирования бизнес-процессов и UML-моделирования.
Проектирование
За этапом определения требований, завершающимся утверждением технического задания, следует этап проектирования. Осуществляется он, как правило, архитекторами приложений, принимающими решения относительно архитектуры и составных частей создаваемого решения, а также технологий их реализации, и системными аналитиками, осуществляющими проектирование данных и классов приложения, а иногда и прототипирование пользовательских интерфейсов. Результатом этого этапа обычно является документ, часто называемый техническим проектом и содержащий диаграммы классов, модели данных, прототипы пользовательских интерфейсов.
Обычно на этом этапе к модели, созданной бизнес-аналитиками, добавляются диаграммы классов создаваемых приложений и диаграммы развертывания создаваемого решения, а также диаграммы, описывающие логическую модель данных и их физическую структуру для выбранной СУБД.
Какие инструменты применяются на этом этапе? Для создания диаграмм классов и диаграмм развертывания используются вышеперечисленные инструменты UML-моделирования. Для проектирования данных обычно применяют такие инструменты, как CA AllFusion Data Modeler (бывший ERwin), Sybase Power Designer, Oracle Designer, а также аналогичные инструменты компаний Embarcadero и Popkin Software. Для СУБД, разработанных компанией Microsoft, можно достаточно успешно применять и Microsoft Visio. Перечисленные инструменты позволяют создать как минимум скрипт для генерации базы данных, а различия между ними заключаются в способах управления генерацией серверного кода, связанного с созданием триггеров и хранимых процедур.
Пример логической модели данных (CA AllFusion ERwin Data Modeler)
Отметим, что если инструменты UML-моделирования пока применяются далеко не везде, то использование средств проектирования данных сейчас типично даже для маленьких компаний. Эту категорию инструментов вполне можно отнести к разряду обязательных.
Прототипирование пользовательского интерфейса, если таковое на данном этапе производится, может потребовать применения либо средства рисования изображений форм будущего приложения (например, Microsoft Visio или графических редакторов), либо непосредственно средств разработки приложений.
Таким образом, на этапе проектирования нужны средства моделирования и проектирования данных и UML-моделирования, а в некоторых случаях - средства создания изображений форм.
Разработка продукта
На этапе собственно разработки создается код приложения в соответствии с техническим проектом, в том числе и серверный код, реализующий функциональность, отсутствующую в модели данных. На этом этапе основным инструментом, обязательным к применению, является средство разработки приложений. Выбор средства разработки определяется в первую очередь платформой (Windows, .NET, Java/J2EE, Linux/UNIX) и архитектурой (приложения с графическим интерфейсом, консольные приложения и службы, Web-приложения) и в настоящее время достаточно разнообразен. Средства разработки Java/J2EE-приложений производят компании IBM, Oracle, Borland, средства разработки Windows-приложений - Microsoft, Borland, Sybase, средства разработки .NET-приложений - Microsoft и Borland, средства разработки приложений для Linux - Borland и некоторые другие компании.
Создание кода приложения (Microsoft Visual Studio .NET)
Помимо средств разработки на этом этапе иногда требуются различные дополнительные библиотеки компонентов, предназначенные для применения на конкретной платформе или вместе с определенными средствами разработки. Такие компоненты поставляет большое количество независимых разработчиков, а также многие поставщики коммерческих продуктов, на основе которых предполагается создание решений другими разработчиками (примерами таких продуктов являются многие геоинформационные системы, CAD-приложения и некоторые серверные продукты).
Естественно, что при создании решений на базе какого-либо серверного продукта (СУБД, J2EE-сервера, сервера обмена сообщениями и т.д.) на данном этапе следует иметь этот продукт. Во многих случаях специально для разработчиков решений производители таких продуктов выпускают версии, предназначенные для разработки и отладки приложений, но не для промышленной эксплуатации.
На этапе разработки приложения средства моделирования тоже применяются, особенно в том случае, когда они могут осуществлять не только генерацию кода на различных языках программирования, но и поддерживать обратное проектирование, создавая диаграмму классов на основе готового приложения либо позволяя синхронно редактировать и код, и модель. Функция синхронного изменения кода и модели существенно упрощает многие процессы, сопровождающие собственно разработку, так что если есть возможность выбора инструментов, то стоит обратить внимание на ее поддержку (например, синхронное изменение кода и модели поддерживают некоторые редакции инструмента UML-моделирования Borland Together).
Нередко на этапе создания приложений применяются средства оптимизации кода и его отладки. Такие инструменты могут входить в состав средств разработки или поставляться отдельно.
Оптимизация кода приложения (Borland Optimizeit Profiler)
Тестирование и оценка качества
При тестировании продукта проверяется его соответствие требованиям, и в зависимости от этих требований осуществляется определение методик тестирования, создание тестов и выбор соответствующих инструментов.
В современных проектах тестированию подвергаются и пользовательский интерфейс, и производительность приложений, и безопасность данных, и совместимость с различными операционными системами и приложениями. Для этого разработаны соответствующие инструменты, такие как утилиты тестирования баз данных, средства автоматического тестирования пользовательского интерфейса, средства нагрузочного тестирования, средства тестирования ошибок исполнения, средства тестирования безопасности приложений. Как правило, подобные инструменты содержат средства создания сценариев, согласно которым производится автоматизированное тестирование, то есть многократное выполнение набора действий с одновременным сбором статистики отказов, времени выполнения операций и иных сведений, связанных с оценкой качества продукта.
Основными производителями средств тестирования в настоящее время являются компании Compuware, Segue, Mercury Interactive, IBM/Rational, Borland. Каждая из них производит несколько инструментов автоматизированного тестирования, включая средства нагрузочного тестирования, проверки пользовательских интерфейсов, тестирования ошибок исполнения.
Тестирование производительности приложений (Rational Test Realtime)
Кроме инструментов тестирования, для оценки качества продукта нередко применяются анализаторы исходного кода приложения на предмет корректности проектирования иерархии классов, стиля написания кода и иных особенностей реализации продукта. Они могут быть выполнены в виде отдельных приложений либо входить в состав средств моделирования (в частности, в некоторые редакции Borland Together) или средств разработки приложений.
Оценка качества кода (Borland Together)
Если приложение предназначено для работы под управлением различных операционных систем и их языковых версий (например, разных 32-разрядных версий и редакций Microsoft Windows), то специалистам по тестированию могут пригодиться средства создания виртуальных машин, позволяющие иметь на одном компьютере несколько различных операционных систем, загруженных одновременно, и организовывать между ними сетевое взаимодействие (о продуктах данной категории мы планируем рассказать в отдельной статье). Из ПО такого класса широко распространены продукты компаний Microsoft и VMWare. При тестировании программ для установки приложений могут применяться также средства резервного копирования и восстановления образов жестких дисков, выпускаемые компаниями Symantec, PowerQuest и др.
Документирование
Документирование проекта осуществляется разными специалистами. Руководство пользователя обычно создается техническим писателем, и его основной инструмент - это текстовый редактор и какое-нибудь не слишком сложное средство обработки графических изображений, с помощью которого можно добавить к снимкам экрана стрелки, выноски и иные элементы, которые принято изображать на иллюстрациях подобных документов. Примерно такие же инструменты нужны и авторам учебных курсов по продукту и маркетинговых материалов, а возможно, им понадобятся средства подготовки презентаций наподобие Microsoft PowerPoint.
Документацию же по развертыванию и сопровождению продукта, равно как и иные технические документы, обычно создают аналитики или специалисты по развертыванию. В этом случае им может потребоваться многое из того, что было перечислено выше, как-то: средства управления требованиями, инструменты моделирования данных и UML-моделирования - нередко значительная часть таких документов состоит именно из отчетов по моделям. При этом чем аккуратнее велась работа над моделью, тем проще создавать проектную документацию.
На основе руководства пользователя с помощью специальных инструментов обычно генерируются файлы справочной системы. В простейшем случае файл справочной системы можно создать с помощью Microsoft Word и утилит от Microsoft для создания help-файлов, включаемых в состав многих средств разработки, но при большом объеме работы нередко используются специализированные средства таких компаний, как Blue Sky Software, EC Software, JGsoft.
Подготовка файла справочной системы (EC Software Help & Manual)
Внедрение и сопровождение
Перед внедрением продукта обычно создаются дистрибутивные приложения, облегчающие этот процесс, - именно их мы запускаем, устанавливая на компьютер тот или иной продукт. Для создания дистрибутивных приложения также применяются специализированные средства, лидерами рынка которых являются компании InstallShield Software и Wise Solutions. Нередко в состав средств разработки входят специализированные версии указанных продуктов, учитывающие их специфику (например, возможность включения в дистрибутив библиотек, входящих в состав данного средства разработки).
Подготовка дистрибутива приложения (InstallShield Express)
На этапе сопровождения продукта, как показывает практика, может понадобиться все, что было произведено при работе над проектом, и соответственно любой из инструментов.
Коллективная разработка и управление проектом
Если над какой-либо частью проекта работает более одного человека, полезными при разработке могут оказаться средства контроля версий (наиболее популярными из них являются Merant PVCS Version Manager и Microsoft Visual SourceSafe). Нередко их применяют при создании не только кода приложения, но и документов (например, технического задания) либо моделей. В крупных проектах часто используются и средства управления изменениями. Подобные продукты позволяют хранить в единой базе данных все составные части проекта и их версии и упрощают управление версиями кода, моделей, требований, а также дают возможность отслеживать влияние изменений в одной части проекта на остальные его части. Из самых популярных сегодня средств управления изменениями следует отметить продукты компаний Borland и IBM/Rational.
Типичный интерфейс средства управления изменениями (Borland StarTeam)
Ни один проект не обходится без человека, несущего за него ответственность и осуществляющего планирование деятельности всех специалистов и управление всеми процессами разработки. Хотя планировать работу можно и на бумаге, но в последнее время основным инструментом руководителя проекта (а в крупных проектах - менеджеров, отвечающих за составные части проекта) служит какое-либо специализированное средство управления проектами. Лидером среди продуктов данной категории является семейство продуктов Microsoft Project.
Пример плана проекта разработки программного продукта (Microsoft Project)
Заключение
еречисляя инструменты, которые могут понадобиться при разработке приложений, мы, естественно, назвали не все возможные варианты. В одних проектах могут потребоваться генераторы отчетов, в других - средства для работы с графикой, в третьих - инструменты Web-дизайна, в четвертых - CAD- или ГИС-инструменты. При этом, как мы убедились, в самых простых случаях можно обойтись средством разработки и текстовым редактором - этот набор может оказаться достаточно эффективным, если проект не слишком крупный.
Все остальные категории средств, перечисленных в данной статье, по сути дела, вовсе не являются строго обязательными к применению при разработке приложений. Однако, как показывает практика, работать с их помощью намного проще.