Новые средства и среды для разработки. Инструментальные среды разработки и сопровождения программных средств

Обеспечиваем всестороннее рассмотрение всех элементов

Зачем нужно определение требований

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

Место среды разработки в контексте

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

На рисунке 1 изображен центр обеспечения качества (Center of Excellence), отвечающий за создание и обслуживание среды разработки. Эта среда используется в проектах разработки, которые, в свою очередь, создают и обслуживают программоемкие системы (либо какие-то другие программные активы, например, компоненты или сервисы). Такая простая визуализация позволяет уточнить различия между ролью центра обеспечения качества (включая роли членов коллектива, процессы и ключевой узел – среду разработки) и проектами, которые используют эту среду разработки (а также их роли, процессы и узлы).

Элементы среды разработки

Согласно мнению экспертов по программному обеспечению IBM Rational, среда разработки состоит из следующих шести элементов, каждый из которых показан на рисунке 2 и подробно описан ниже:

• Методика (Method)
• Средства (Tools)
• Подготовка (Enablement)
• Организация (Organization)
• Внедрение (Adoption)

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

• Персонал – это организация и подготовка.
• Процесс – это методика.
• Технология – это средства и инфраструктура.

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

Методика (Method)

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

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

Средства (Tools)

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

Ключевые элементы, относящиеся к инструментальным средствам:

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

Подготовка (Enablement)

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

Ключевые элементы, относящиеся к подготовке:

• Учебные программы и курсы. Они охватывают разнообразные потребности – от обучения опытных специалистов деталям среды разработки до всеобъемлющей программы переподготовки специалистов.
• Инструктивные материалы. Применяются специалистами при консультировании менее опытных коллег.
• Топология развертывания подготовки. Топологию развертывания необходимо принимать во внимание, например, когда подготовка специалистов организуется посредством Web-обучения. Опять же для размещения материалов необходим Web-сервер, а рабочие станции должны быть оснащены Web-браузерами. Топология развертывания может также указывать помещения и классы, необходимые для проведения аудиторного обучения.

Организация (Organization)

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

Ключевые элементы, относящиеся к организации:

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

Инфраструктура (Infrastructure)

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

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

Ключевые элементы, относящиеся к инфраструктуре:

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

Внедрение (Adoption)

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

Ключевые элементы, относящиеся к внедрению:

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

Контекст решения

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

• Функциональность представляет схему или порядок разработки программного обеспечения, обеспечиваемые средой разработки. Реализация этих требований вынуждает учитывать все упомянутые ранее элементы. Например, порядок управления требованиями (см. рисунок 3) поддерживается следующими аспектами:
  • Методика управления требованиями.
  • Инструментальные средства управления требованиями.
  • Обучение и наставничество по вопросам управления требованиями.
  • Группа поддержки, умеющая решать вопросы управления требованиями.
  • Аппаратное и программное обеспечение для поддержки элементов, связанных с управлением требованиями.
  • Соответствующее внедрение в проектах порядка управления требованиями.

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

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

Еще одним важным ограничением при рассмотрении возможности изменения существующей среды разработки является, конечно, окупаемость инвестиций (Return On Investment – ROI). Чтобы такая инициатива была успешной, она, несомненно, должна обеспечить положительные результаты, соответствующие бизнес-плану. Каждый аспект среды разработки влияет на ROI как с точки зрения затрат, так и с точки зрения прибыли.

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

Определение, развертывание, управление

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

• Определение среды.
• Развертывание среды.
• Управление средой.

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

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

Определение

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

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

Таблица 1. Аспекты определения

Развертывание

Развертывание среды разработки поднимает специфические вопросы относительно каждого элемента (см. таблицу 2).

Таблица 2. Аспекты развертывания

Ключевые элементы методики :

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

Ключевые элементы инструментальных средств :

• Выполнение локальной настройки. Любая локальная настройка инструментальных средств применяется для автоматизации настройки локальной методики.
• Установка инструментальных средств. Делает установленные средства (и интеграцию их) доступными для специалистов.
• Миграция локальных данных. Например, может возникнуть необходимость переноса данных из существующего набора инструментальных средств в новый.

Ключевые элементы подготовки :

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

Ключевые элементы организации :

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

Ключевые элементы инфраструктуры :

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

Ключевые элементы внедрения :

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

Управление

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

Таблица 3. Аспекты управления

Ключевые элементы методики :

• Сбор отзывов по методике. Ключевым аспектом управления средой разработки является ее постоянное совершенствование. Поэтому сбор отзывов касается всех элементов. Отзывы обычно собираются субъективно при помощи, например, опросных листов.

Ключевые элементы инструментальных средств :

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

Ключевые элементы подготовки :

• Обучение исполнителей. Назначить кураторов проектов, чтобы исполнители знали, как использовать среду.
• Сбор отзывов по подготовке, т.е. по обучению или наставничеству.

Ключевые элементы организации :

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

Ключевые элементы инфраструктуры :

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

Ключевые элементы внедрения :

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

Взаимозависимости

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

Вот несколько примеров зависимостей между элементами:

• Методика (методика) ссылается на доступные обучающие курсы (подготовка).
• Инструментальные средства (средства) автоматизируют задачи (методика).
• Административные роли (организация) определены для поддержки инструментальных средств (средства).
• Серверы (инфраструктура) предоставлены для размещения набора инструментальных средств (средства).
• Внедрение приемов работы (внедрение) оценивается с использованием определенного подхода (методика).

Заключение

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

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

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

4.5. Интегрированные среды разработки

1. Visual Studio 97 – первая выпущенная версия Visual Studio. В ней впервые были собраны вместе различные средства разработки ПО. Система была выпущена в двух версиях: Professional и Enterprise. Она включала в себя Visual Basic 5.0, Visual C++ 5.0, Visual J++ 1.1, Visual FoxPro 5.0, впервые появилась среда разработки ASP – Visual InterDev. Visual Studio 97 была первой попыткой Microsoft создать единую среду для разработки на разных языках программирования: Visual C++, Visual J++, Visual InterDev и MSDN использовали одну среду, называемую Developer Studio. Visual Basic и Visual FoxPro применяли отдельные среды для разработки.
2. Visual Studio 6.0 вышла в июне 1998 г.. Это последняя версия Visual Studio, работающая на платформе Win9x. По-прежнему популярна среди программистов, использующих Visual Basic. Данная версия являлась основной средой разработки приложений под Windows от Microsoft, до появления платформы.NET.
3. Visual Studio .NET (кодовое имя Rainier; внутренняя версия 7.0) выпущена в феврале 2002 года (включает.NET Framework 1.0). Service Pack 1 для Visual Studio .NET (2002) выпущен в марте 2005 г.
4. Visual Studio .NET 2003 (кодовое имя Everett; внутренняя версия 7.1) появилась в апреле 2003 года (включает.NET Framework 1.1). Service Pack 1 для Visual Studio .NET 2003 выпущен 13 сентября 2006 г.
5. Visual Studio 2005 (кодовое имя Whidbey; внутренняя версия 8.0) выпущена в конце октября 2005 года, последняя официально работающая на Windows 2000 (включает.NET Framework 2.0). В начале ноября 2005 года также вышла серия продуктов в редакции Express: Visual C++ 2005 Express, Visual Basic 2005 Express, Visual C# 2005 Express и др. 19 апреля 2006 г. редакция Express стала бесплатной. Service Pack 1 для VS2005 и всех Express-редакций выпущен 14 декабря 2006 года. Дополнительный патч для SP1, решающий проблему совместимости с Windows Vista выпущен 6 марта 2007 г.
6. Visual Studio 2008 (кодовое имя Orcas) выпущена 19 ноября 2007 г., одновременно с.NET Framework 3.5. Нацелена на создание приложений для ОС Windows Vista (но поддерживает и XP), Office 2007 и веб-приложений. Включает в себя LINQ, новые версии языков C# и Visual Basic. В студию не вошел Visual J#. С 28 октября 2008 года впервые доступна версия на русском языке.
7. Visual Studio 2010 (кодовое имя Hawaii, для Ultimate – Rosario) выпущена 12 апреля 2010 года вместе с.NET Framework 4.0. Visual Studio включает поддержку языков C# 4.0 и Visual Basic .NET 10.0, а также языка F#, отсутствовавшего в предыдущих версиях.

Среда Visual Studio 2010 позволяет эффективно создавать сложные приложения в течение короткого периода времени. Модель данной среды существенно богаче ранних версий и использует такие понятия, как решение (solution), проект, пространство имен ( namespace ) и сборка (assembly). Понятие проекта присутствует во многих средах, например, в среде Delphi. Файл проекта содержит перечисление исходных файлов и прочих ресурсов, из которых система будет строить приложение . В решение среды Visual Studio входят несколько проектов, которые могут быть зависимыми или независимыми друг от друга. Выделяется стартовый проект . Понятие сборки исходит из общеязыковой исполнительной среды CLR (Common Language Runtime). Среда CLR является наиболее революционным изобретением, с появлением которого процесс написания и выполнения приложений становиться принципиально другим.

Компилятор преобразует файлы с исходными кодами в коды на промежуточном языке MSIL ( Microsoft Intermediate Language ). Вместе с метаданными эти коды записывают PE-файлы ( Portal Executable), имеющие расширение exe или dll в зависимости от типа проекта. Также может быть получен модуль с расширением netmodule, который не содержит метаданных.

Всего имеется 12 типов проектов. При загрузке PE-файлы "на лету" транслируются в команды реального процессора. Каркас Framework. NET , обеспечивающий выполнение программ, не входит в Visual Studio, а является настройкой над операционной системой. Это аналог виртуальной Java -машины.

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

На уровне языка C# пространства имен, аналогично пакетам в Java , служат для структурирования проекта. Пространство имен включает один или несколько классов. В одном исходном файле может определяться несколько пространств имен и в тоже время одно пространство имен может определяться в нескольких файлах. И даже класс может располагаться в нескольких файлах (partial classes).

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

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

Экосистема Eclipse относится к консолидированным технологиям, годом широкого распространения которой является 2007-й. Система реализована на языке Java и изначально представляла собой полноценную интегрированную среду для языка Java . В дальнейшем стали поддерживаться и другие языки. Первые версии были неудобны, поскольку целевой продукт вынуждено включал лишнюю функциональность. Начиная с третьей версии была переработана архитектура всей системы с целью максимального разделения модулей и взаимосвязи между ними. При этом модули Eclipse, образованные из согласованных наборов классов, давали функциональность целых подсистем, таких как подсистемы помощи, обновления продукта, обучения, презентации, многоязыковой поддержки и множество других. Разрабатывая приложение , теперь можно постепенно наращивать функциональность, подключая уже готовые бесплатные компоненты. В терминологии Eclipse эти компоненты называются "подключаемыми модулями", или "плагинами" (Plugins). Такая технология становится типичной для развитых операционных сред. Платформа на основе этой технологии получила название

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ

ДОНЕЦКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ

Кафедра прикладной математики и теории систем управления

РЕФЕРАТ

«Информатика и программирование»

„ Передовые технологии и популярные средства разработки программного обеспечения ”

Доложилa:

студентка группы 2-В

М.А. Матиишина

Преподаватель: к.е.н., с.н.с.

С. Н. Мичкивский

Донецк 2013

Введение

1. История

2. Основные особенности методологии RAD

2.1 CASE средства

2.2 Применение объектно-ориентированных методов

2.3 Среды разработки, использующие принципы RAD

2.4 Когда применяется RAD.

3. Жизненный цикл методологии RAD

3.1 Фаза анализа и планирования требований

3.2 Фаза проектирования

3.3 Фаза построения

3.4 Фаза внедрения

Заключение

Введение

На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей (чему в значительной степени способствовал прогресс в области вычислительной техники, а также появление удобного графического интерфейса пользователя в системном программном обеспечении) потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспечения -- инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информационных систем. Например, технология Rapid Application Development (RAD).

программный обеспечение ориентированный жизненный

1. История

Концепция RAD стала ответом на неуклюжие методы разработки программ 1970-х и начала 1980-х годов, такие как «модель водопада» (англ. Waterfall model). Эти методы предусматривали настолько медленный процесс создания программы, что зачастую даже требования к программе успевали измениться до окончания разработки. Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную книгу, в которой детально изложил концепцию RAD и возможности её применения. В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов. Именно средства разработки, основанные на RAD, имеют наибольшую популярность среди программистов.

2 . Основные особенности методологии RAD

Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений -- RAD (Rapid Application Development). Данная методология охватывает все этапы жизненного цикла современных информационных систем.

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

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

· небольшой команде программистов (обычно от 2 до 10 человек);

· тщательно проработанный производственный график работ, рассчитанный на сравнительно короткий срок разработки (от 2 до 6 мес.);

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

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

Основные принципы методологии RAD можно свести к следующему:

· используется итерационная (спиральная) модель разработки;

· полное завершение работ на каждом из этапов жизненного цикла не обязательно;

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

· необходимо применение CASE-средств и средств быстрой разработки приложений;

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

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

· тестирование и развитие проекта осуществляются одновременно с разработкой;

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

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

2.1 Средства автоматизации разработки программ (CASE-средства)

В основных принципах методологии RAD, появляется такое понятие как CASE средства. Так вот, средства автоматизации разработки программ (CASE-средства)-- инструменты автоматизации процессов проектирования и разработки программного обеспечения для системного аналитика разработчика ПО и программиста. Первоначально под CASE-средствами понимались только инструменты для упрощения наиболее трудоёмких процессов анализа и проектирования, но в дальнейшем CASE-средства стали определять как программные средства для поддержки процессов жизненного цикла ПО.

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

* подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

* широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

2.3 Применение объектно-ориентированных методов

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

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

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

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

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

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

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

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

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

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

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

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

Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их называем потому, что они не ориентированы на разработку только приложений баз данных -- с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причем программы, разрабатываемые с помощью универсальных систем, могут взаимодействовать практически с любыми системами управления базами данных. Это обеспечивается как использованием драйверов ODBC или OLE DB, так и применением специализированных средств (компонентов).

2.4 Среды разработки, использующие принципы RAD

· Borland Delphi

· Borland C++ Builder

· Microsoft Visual Studio

· Macromedia Flash

· Macromedia Authorware

· Macromedia Director

· Visual DataFlex

Быстрая разработка приложений Rapid Application Development (RAD) - это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех месяцев путем использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях -обследование организации, выработка требований к системе. Причины популярности RAD вытекают из тех преимуществ, которые обеспечивает эта технология.Наиболее существенными из них являются:

§ высокая скорость разработки;

§ низкая стоимость;

§ высокое качество.

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

Логика приложения, построенного с помощью RAD, является событийно-ориентированной. Это означает следующее: каждый объект, входящий в состав приложения, может генерировать события и реагировать на события, генерируемые другими объектами. Примерами событий могут быть: открытие и закрытие окон, нажатие кнопки, нажатие клавиши клавиатуры, движение мыши, изменение данных в базе данных и т. п.

Разработчик реализует логику приложения путем определения обработчика каждого события -- процедуры, выполняемой объектом при наступлении соответствующего события. Например, обработчик события «нажатие кнопки» может открыть диалоговое окно. Таким образом, управление объектами осуществляется с помощью событий.

Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPDATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы данных при операциях удаления, вставки и обновления, а также автоматическую генерацию первичных ключей.

2.5 Когда применяется RAD

Применение технологии RAD целесообразно, когда: требуется выполнение проекта в сжатые сроки (90 дней). Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня. Если система проектируется долго, то весьма высока вероятность, что за это время существенно изменятся фундаментальные положения, регламентирующие деятельность организации, то есть, система морально устареет еще до завершения ее проектирования.

Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта. Проект большой, но поддается разделению на более мелкие функциональные компоненты. Если предполагаемая система велика, необходимо, чтобы ее можно было разбить на мелкие части, каждая из которых обладает четкой функциональностью. Они могут выпускаться последовательно или параллельно (в последнем случае привлекается несколько RAD групп).·

ПО не обладает большой вычислительной сложностью. Современные средства быстрой разработки windows-при-ложений, так называемые rad-средства (rad расшифровывается как rapid application development), обладают в той или иной степени почти всеми возможностями реализации в приложениях подобных интерфейсных элементов. Многие из них позволяют осуществлять доступ к базам данных, в том числе и к серверным БД. borland delphi, на взгляд автора, является в этом отношении наиболее простым и удобным в использовании средством.

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

3 . Жизненный цикл методологии RAD

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

· фаза анализа и планирования требований;

· фаза проектирования;

· фаза построения;

· фаза внедрения.

3 .1 Фаза анализа и планирования требований.

На фазе анализа и планирования требований выполняются следующие работы:

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

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

· проводится описание информационных потребностей;

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

· определяются временные рамки для каждой из последующих фаз;

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

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

3 .2 Фаза проектирования

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

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

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

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

На этой же фазе происходит определение набора необходимой документации.

Результатами данной фазы являются:

· общая информационная модель системы;

· функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

· точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

· построенные прототипы экранов, диалогов и отчетов.

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

3 .3 Фаза построения

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

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

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

Завершается физическое проектирование системы, а именно:

· определяется необходимость распределения данных;

· производится анализ использования данных;

· производится физическое проектирование базы данных;

· определяются требования к аппаратным ресурсам;

· определяются способы увеличения производительности;

· завершается разработка документации проекта.

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

3 .4 Фаза внедрения

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

Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, еще на этапе проектирования системы.

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

Заключение

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

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

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

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

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

Список источников

1. http://ru.wikipedia.org

2. http://www.inforazrabotky.info

3. http://brain.botik.ru

4. http://promidi.by.ru

5. http://www.citforum.ru

6. Трофимов С.А. CASE-технологии: практическая работа в Rational Rose.

7. http://vk.com/away.php?to=https%3A%2F%2Fdrive.google.com%2Ffolderview%3Fid%3D0B4QYrT5wARvMdUttbnJ4N1F0bFk%26usp%3Dsharing&post=-58064243_12

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

Подобные документы

Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.

презентация , добавлен 19.09.2016


Понятие, сущность и структура жизненного цикла программного обеспечения, описание технологии его проектирования, разработки и сопровождения. Сущность и основные положения международного стандарта ISO/IEC 12207. Перечень основных принципов методологии RAD.

реферат , добавлен 30.11.2010


Современные методологические проблемы разработки и внедрения программного обеспечения ERP систем. Основные концептуальные подходы к методологии разработки и внедрения программного обеспечения. Исследование методологии ASAP: ее сильные и слабые стороны.

дипломная работа , добавлен 29.04.2011


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

реферат , добавлен 24.06.2009


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

курсовая работа , добавлен 07.04.2015


Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.

курсовая работа , добавлен 26.09.2014


Понятие технологии разработки программы. Основа проектирования программного обеспечения. Модели жизненного цикла, возникшие исторически в ходе развития теории проектирования программного обеспечения. Спиральная (spiral), каскадная и итерационная модели.

презентация , добавлен 11.05.2015


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

презентация , добавлен 02.04.2013


Оценка финансовой, стратегической ценности и уровня рисков проекта. Классификация проектов: "свой" заказчик, продукт под заказ, тиражируемый продукт, аутсорсинг. Организация процесса разработки программного обеспечения, методологии его проектирования.

презентация , добавлен 07.12.2013


Стадии разработки программного средства. Средства, методологии и методы его разработки. Оценка надежности и качества проекта. Обоснование необходимости разработки программы. Тестирование как процесс выполнения тестовой программы с намерением найти ошибки.

Выбор среды разработки

Интегрированная среда разработки, ИСР (англ. IDE, Integrated development environment или integrated debugging environment) -- система программных средств, используемая программистами для разработки программного обеспечения (ПО) .

Среда разработки включает в себя:

Текстовый редактор;

Компилятор и/или интерпретатор;

Средства автоматизации сборки;

Отладчик.

ИСР иногда содержит также средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов -- для использования при объектно-ориентированной разработке ПО. Хотя и существуют ИСР, используемые для нескольких языков программирования -- такие, как Eclipse, NetBeans, Embarcadero RAD Studio, Qt Creator или Microsoft Visual Studio, но обычно в ИСР используется один определённый язык программирования - как, например, Visual Basic, Delphi, Dev-C++.

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

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

IDE обычно представляет из себя единственную программу, в которой проводилась вся разработка. Она обычно содержит много функций для создания, изменения, компилирования, развертывания и отладки программного обеспечения. Цель среды разработки заключается в том, чтобы абстрагировать конфигурацию, необходимую, чтобы объединить утилиты командной строки в одном модуле, который позволит уменьшить время, чтобы изучить язык, и повысить производительность разработчика. Также считается, что трудная интеграция задач разработки может далее повысить производительность. Например, IDE позволяет проанализировать код и тем самым обеспечить мгновенную обратную связь и уведомить о синтаксических ошибках. В то время как большинство современных IDE является графическим, они использовались еще до того, как появились системы управления окнами (которые реализованы в Microsoft Windows или X11 для *nix-систем). Они были основаны на тексте, используя функциональные клавиши или горячие клавиши, чтобы выполнить различные задачи (например, Turbo Pascal). Использование IDE для разработки программного обеспечения является прямой противоположностью способа, в котором используются несвязанные инструменты, такие как vi (текстовый редактор), GCC (компилятор), и т.п.

На данный момент существуют несколько сред для разработки приложений на языке C#, основные из них приведены в таблице 1.1.

Таблица 1.1 - Сравнение сред разработки C#

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

Лицензия LGPL позволяет линковать с данной библиотекой или программой программы под любой лицензией, несовместимой с GNU GPL, при условии, что такая программа не является производной от объекта, распространяемого под (L)GPL, кроме как путём линкования. Главное различие между GPL и LGPL в том, что последняя позволяет и такое линкование с данным объектом других, которое создаёт производную от данного работу, если лицензия слинкованных объектов позволяет «модификации для внутреннего использования потребителем и обратную разработку для отладки таких модификаций». Т.е. LGPL, в отличие от GPL позволяет связывание библиотеки с любой программой, не обязательно свободной.

Закрытое (проприетарное) программное обеспечение (англ. proprietary software) -- программное обеспечение, являющееся частной собственностью авторов или правообладателей и не удовлетворяющее критериям свободного ПО (наличия открытого программного кода недостаточно). Правообладатель проприетарного ПО сохраняет за собой монополию на его использование, копирование и модификацию, полностью или в существенных моментах. Обычно проприетарным называют любое несвободное ПО, включая полусвободное.

Geany -- свободная среда разработки программного обеспечения, написанная с использованием библиотеки GTK2. Доступна для следующих операционных систем: BSD, Linux, Mac OS X, Solaris и Windows. Geany распространяется согласно GNU General Public License. Geany не включает в свой состав компилятор. Вместо этого используется GNU Compiler Collection (или любой другой компилятор) для создания исполняемого кода.

Microsoft Visual Studio -- линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact Framework и Microsoft Silverlight. Visual Studio включает в себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный отладчик может работать как отладчик уровня исходного кода, так и как отладчик машинного уровня. Остальные встраиваемые инструменты включают в себя редактор форм для упрощения создания графического интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы данных. Visual Studio позволяет создавать и подключать сторонние дополнения (плагины) для расширения функциональности практически на каждом уровне, включая добавление поддержки систем контроля версий исходного кода (как например, Subversion и Visual SourceSafe), добавление новых наборов инструментов (например, для редактирования и визуального проектирования кода на предметно-ориентированных языках программирования или инструментов для прочих аспектов цикла разработки программного обеспечения (например, клиент Team Explorer для работы с Team Foundation Server).

MonoDevelop -- свободная среда разработки, предназначенная для создания приложений C#, Java, Boo, Nemerle, Visual Basic .NET, Vala, CIL, C и C++. Также планируется поддержка Oxygene со стороны Embarcadero Technologies. Изначально это был порт SharpDevelop на Mono/GTK+, но с того времени проект далеко ушёл от своего начального состояния. MonoDevelop является частью проекта Mono.

SharpDevelop -- свободная среда разработки для C#, Visual Basic .NET, Boo, IronPython, IronRuby, F#, C++. Обычно используется теми, кто не хочет пользоваться Visual Studio .NET. Существует также форк на Mono/Gtk+ -- MonoDevelop. SharpDevelop 2.0 предоставляет интегрированный отладчик, который использует собственные библиотеки и взаимодействует с исполняющей средой.NET через COM Interop. Хотя SharpDevelop 2.0 (как и VS2005) использует файлы проекта в формате MSBuild, он по-прежнему может использовать компиляторы от.NET Framework 1.0 и 1.1, а также от Mono.

Для разработки необходимо активно использовать все средства языка программирования. Однако среда MonoDevelop использует собственный компилятор, который не полностью поддерживает язык С# в силу того, что является свободной мультиплатформенной разработкой, независимой от создателей языка. Хотя она и обеспечивает мультиплатформенность, но невозможно предсказать поведение языка в новых версиях. А одной из ключевых составляющих проекта является его отказоустойчивость и стабильность и в то же время мультиплатформенность не требуется (пользователей 1С на Linux исчезающе мало). Поэтому эта среда не подходит для разработки данного проекта.

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

Microsoft Visual Studio также не лишена недостатков. Основными из них являются тяжеловесность, требующая довольно большой вычислительной мощности компьютера; платность; отсутствие мультиплатформенности. Несмотря на эти недостатки, Visual Studio остается предпочитаемой средой разработки большинства C# программистов. Причиной этому является полная поддержка языка, расширенные средства разработки, энергично развивающаяся документация и сама среда. Данную среду разработки будем использовать в проекте.

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

Разработка приложений в современных ИТ-проектах

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

Особенности современных ИТ-проектов

Если еще пять-семь лет назад были широко распространены проекты, связанные с заказной разработкой уникальных приложений (и несколько реже - решений на основе готовых компонентов, предназначенных для конкретной предметной области) и выполняемые силами эрудированных программистов широкого профиля, владеющих и смежными специальностями (например, умеющих администрировать локальные сети и СУБД), то сегодня в первую очередь заказываются проекты внедрения готовых бизнес-приложений и ERP-систем, в рамках которых нередко выполняются проекты по разработке решений на базе все тех же готовых бизнес-приложений. Причиной этого является, с одной стороны, осознание руководителями большинства компаний того факта, что, как бы их компания ни претендовала на уникальность в своей маркетинговой стратегии, по существу и ее производство, и отдельные аспекты ее деятельности являются вполне типовыми, а с другой стороны - осознание производителями бизнес-приложений неуникальности бизнес-процессов большинства компаний и создание ими широкого спектра типовых решений с одновременным предоставлением услуг по их внедрению, сопровождению и обновлению своими силами или силами партнеров.

Переход к разделению труда в проектах по разработке ПО

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

Изменение требований к приложениям

Говоря о проектах по разработке приложений и о связанных с разработкой приложений частях комплексных ИТ-проектов, следует заметить, что сегодня наиболее актуальным становится создание корпоративных решений на основе не только СУБД, но и других продуктов - офисных приложений, GIS- и CAD-систем, средств бизнес-анализа, специализированных серверных продуктов, систем управления предприятием и других бизнес-приложений. Требования к защищенности создаваемых решений также заметно отличаются от тех, что существовали еще три года назад. Наконец, одной из важных тенденций является рост интереса к приложениям для мобильных устройств и приложений, способных работать автономно и при необходимости синхронизироваться с информационной системой предприятия.

Из иных тенденций, проявившихся в последнее время в области разработки корпоративных решений, следует отметить растущую потребность компаний в средствах бизнес-анализа, входящих в состав имеющихся решений или существующих в виде отдельных инструментов. Несмотря на то что создание приложений с применением бизнес-аналитики затруднено из-за того, что сегодня вопросы стандартизации доступа к данным многомерных хранилищ и языка запросов к ним остаются актуальными, в руках разработчиков уже имеется достаточно средств решения подобных задач для наиболее популярных аналитических платформ как от поставщиков самих аналитических платформ (например, Oracle, Microsoft и Hyperion), так и от компаний, специализирующихся на инструментах анализа данных (Cognos, ProClarity и Business Objects). Кроме того, средства бизнес-анализа (Business Intelligence and Report Tools, BIRT) доступны и для платформы Eclipse, занимающей сейчас половину рынка средств разработки Java-приложений.

Вовлечение заказчика в процесс разработки

Оценка вклада разработчиков приложений в успех бизнеса компании-заказчика, равно как и оценка качества самого процесса разработки и его результата всегда являлась спорным вопросом и поводом для непонимания и конфликтов. Однако в последнее время появились методы оценки зрелости процессов разработки и рекомендации, основанные на модели Capability Maturity Model Integration (CMMI), а также ряд методологий разработки приложений, предоставляющий заказчику приложения возможность контролировать ход процесса разработки. Модель CMMI позволяет оценить и усовершенствовать процессы разработки приложений и воспользоваться удачными примерами постановки подобных процессов, и наличие оценки того или уровня зрелости согласно этой модели у компании-разработчика в известной мере является гарантией качества конечного результата процесса разработки продукта в этой компании.

Семейство методологий разработки приложений под общим названием Agile methodologies (включающее, в частности, методологию экстремального программирования, о которой мы писали несколько месяцев назад) предоставляет «рецепты» для ежедневного управления проектной командой, включая, наряду с прочими, принцип разработки, управляемой тестированием (Test-Driven Development, TDD), зарекомендовавший себя в качестве средства получения высококачественного кода. Особенностью данного семейства методологий является вовлеченность заказчика в процесс разработки с тем, чтобы он мог его контролировать на всех этапах.

Самые популярные архитектуры и платформы

Архитектура, ориентированная на сервисы

Одна из современных тенденций развития ИТ-инфраструктуры современных предприятий и архитектур корпоративных приложений - переход к архитектуре, ориентированной на сервисы (Service Oriented Architecture, SOA). Данная архитектура предполагает создание и внедрение распределенных приложений и служб, основанных на применении различных технологий, например веб-служб (так, подобные технологии широко поддерживаются платформой Eclipse и средствами разработки от Borland и Microsoft).

Наиболее популярные платформы

Одна из наиболее заметных тенденций последнего времени проявляется в унификации платформ, для которых создается большинство приложений, и выделении среди них двух лидеров - Windows/Microsoft .NET и Java/J2EE. Это во многом обусловлено способностью указанных платформ обеспечить возможность создания приложений, степень защиты данных в которых, равно как и возможности создания пользовательских интерфейсов и обеспечения доступа к сервисам и данным, отвечают современным требованиям. Впрочем, указанная тенденция уже давно ни для кого не нова.

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

Рост популярности мобильных платформ

Сегодня мобильные приложения разрабатываются примерно для полутора десятков платформ. Согласно проведенному в конце прошлого года исследовательской компанией Evans Data Corp. опросу нескольких сотен разработчиков мобильных приложений, основными лидерами в этой области являются.NET Compact Framework и Java 2 Mobile Edition (J2ME), а также другие платформы Microsoft для мобильных устройств и Embedded Linux (рис. 1).

Рис. 1. Популярность мобильных платформ среди разработчиков (источник - Developers’ Choice Wireless Platforms. Definitive Rankings of Wireless Platform by Developers Worldwide - Evans Data Corp., September 2005)

Тем не менее, согласно тому же опросу, в плане удовлетворения разработчиков качеством инструментов и уровнем поддержки сообщества разработчиков первое место сейчас занимает платформа Nokia Series 60. По прогнозам той же Evans Data Corp., на рынке мобильных платформ ожидается рост доли Embedded Linux.

Что касается средств разработки приложений, для платформы Windows Mobile инструменты от Microsoft существуют уже в течение нескольких лет. Инструменты компании Borland доступны для платформ.NET Compact Framework, Symbian и J2ME. Кроме того, имеются некоторые инструменты разработки мобильных приложений компании Sybase, а также ряда других производителей.

Инструменты для разработчиков сегодня

Узкая специализация разработчиков привела к активному развитию в течение последних пяти лет так называемых средств поддержки жизненного цикла приложений, предназначенных для больших коллективов разработчиков. К подобным средствам относятся средства управления требованиями, моделирования бизнес-процессов, приложений и данных, тестирования и оптимизации приложений, управления коллективной работой, контроля версий, управления изменениями. Производят такие инструменты многие ведущие поставщики ПО: IBM, Computer Associates, Borland, Microsoft, Oracle и ряд других.

В последнее время пристальное внимание инструментам подобного назначения стали уделять многие компании, ранее специализировавшиеся на создании сред разработки (в частности, IBM, Computer Associates, Borland, Microsoft, Oracle и Sybase). Потребность во взаимной интеграции всех этих «тяжелых» инструментов привела к созданию целых платформ для ролевой разработки программного обеспечения и управления жизненным циклом приложений - такие платформы сейчас производятся компаниями Borland, IBM, Microsoft и рядом других.

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

Бесплатные версии коммерческих инструментов

Если вспомнить, что происходило с инструментами для разработки в последние два года, можно заметить, что в последнее время весьма активно проявилась тенденция выпуска ведущими производителям средств разработки их бесплатных версий (причем с неплохими функциональными возможностями) с целью привлечь внимание разработчиков к потенциалу и возможностям полнофункциональных продуктов и платформ, для которых они предназначены. В частности, компания Borland уже примерно три года выпускает бесплатные версии некоторых своих средств разработки. Корпорацией Microsoft недавно было выпущено семейство продуктов Express, включающее несколько инструментов для разработки приложений Windows Forms и ASP .NET. Корпорация Oracle, в свою очередь, также предоставила свободный доступ разработчиков к инструменту Oracle JDeveloper 10g.

Инструменты с открытым кодом

Наблюдается еще одна тенденция, характерная для современного рынка средств разработки, - активный рост популярности платформ и инструментов с открытым исходным кодом, в развитие которых сейчас инвестируется немало средств коммерческими компаниями, в том числе такими известными производителями платформ, как IBM, Novell и Oracle. Среди наиболее ярких примеров следует отметить активное развитие среды Eclipse - универсальной открытой платформы разработки, совместимой с множеством языков, платформ развертывания и технологий, а также проекта Mono реализации части платформы.NET для операционной системы Linux (для последней сейчас активно выпускаются компиляторы и иные инструменты).

Начало проекту Eclipse было положено в 1998 году корпорацией IBM, поставившей перед собой цель создания интегрированной среды Java-разработки нового поколения, расширяемой за счет встраиваемых в нее интегрируемых инструментов, силами нескольких поставщиков Java-инструментов. С этой целью корпорация IBM в конце 2001 года предоставила сообществу Open Source часть исходного кода своего средства разработки Java-приложений WebSphere Studio Workbench и сформировала консорциум Eclipse (включавший представителей компаний Borland, IBM, MERANT, QNX Software Systems, Rational Software, Red Hat, SuSE, TogetherSoft и Webgain) для управления дальнейшим развитием этой среды разработки, преобразованный в дальнейшем в независимую некоммерческую организацию Eclipse Foundation, насчитывающую сегодня 115 членов.

Сегодня, по прошествии пяти лет с момента ее создания, платформа Eclipse стала настолько популярна, что начала вытеснять с рынка широко применявшиеся коммерческие инструменты (например, некоторые средства Java-разработки). Сегодня доля рынка средств разработки Java-приложений, занимаемая Eclipse, составляет примерно 50%. При этом в течение предыдущего года явно наблюдалась тенденция превращения Eclipse из среды Java-разработки в платформу интеграции инструментов для всего жизненного цикла разработки приложений - недавно в рамках консорциума Eclipse были начаты такие проекты, как создание графической среды моделирования, инструментов для архитектуры, ориентированной на сервисы, а также выпущены обновленные версии инструментов тестирования, бизнес-анализа, средств создания web-приложений.

Что касается собственно средств разработки приложений, на основе платформы Eclipse сейчас созданы среды разработки для PHP, Fortran, Macromedia Flex; планируется выпуск ряда инструментов для разработки приложений для встроенных и мобильных платформ. Для платформы Eclipse существуют и коммерческие средства разработки компаний IBM, Borland и SAP.

Самые популярные среды разработки

Согласно опросу 1200 разработчиков, проведенному в июне этого года исследовательской компанией Evans Data Corp., наиболее широко используемой средой разработки оказалась Microsoft Visual Studio .NET (рис. 2).

Рис. 2. Частота использования сред разработки (источник - Developers’ Choice IDE Scorecard - Evans Data Corp., June 2006)

По данным того же опроса, наиболее популярной в плане функциональности средой разработки приложений оказалась IBM Rational Application Developer, признанная участниками опроса лучшей в качестве инструмента моделирования и сборки приложений и обладающей лучшим набором примеров (рис. 3).

Результаты данного опроса отражают уже упомянутые тенденции преобладания двух наиболее популярных платформ (Windows/Microsoft .NET и Java/J2EE - практически все популярные среды разработки предназначены для этих платформ) и роста популярности средств и платформ разработки с открытым кодом (о чем свидетельствует присутствие Eclipse в пятерке самых популярных сред разработки).

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