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

Введение

оворя о разработке программного обеспечения, многие пользователи подразумевают в первую очередь написание кода приложений или, в лучшем случае, еще и внедрение созданных продуктов. Подобная точка зрения часто основана на опыте, полученном в прошлом. Многие IT-специалисты и пользователи, особенно старшего возраста, вышли из научной среды. В 80-е годы программирование нередко дополняло научные исследования и, ученый, по существу, сам ставил себе задачу, выполнял ее и был единственным (или одним из немногих) пользователем созданного приложения. Следствием этого стало то, что в начале 90-х годов в России было довольно много разработчиков (зачастую тех самых бывших ученых, умевших программировать), которые создавали уже отчуждаемые продукты, но при этом сами вели переговоры с заказчиками, проектировали приложения, писали код, готовили проектную документацию, тестировали и внедряли продукт, а нередко заодно и сопровождали рабочие станции пользователей. Естественно, набор инструментов такого разработчика-универсала обычно исчерпывался средством разработки, текстовым редактором для подготовки договоров и документации и, намного реже, средствами проектирования данных и генерации дистрибутивов.

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

Этапы, роли, инструменты…

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

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

Определение требований

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

Какие инструменты требуются бизнес-аналитику? Потребность в инструментах определяется масштабом проекта, требованиями заказчика к оформлению документации, стандартами, принятыми в той или иной компании-разработчике. Бизнес-аналитик может обойтись и текстовым процессором (например, Microsoft Word), изложив требования в виде текста. Однако в последнее время описание требований принято иллюстрировать UML- и IDEF0-диаграммами, описывающими сценарии взаимодействия пользователя с продуктом, порядок передачи сообщений от одних объектов к другим, взаимодействие объектов друг с другом, потоки работ и изменение состояний объектов. Для создания таких диаграмм можно применять Microsoft Visio, Rational Rose, Rational XDE, Borland Together, для создания диаграмм в стандарте IDEF0 наиболее активно используется CA AllFusion Process Modeler (ранее носивший название BPwin).

Какой именно инструмент подходит для данного проекта, во многом зависит от постановки процессов разработки. Если бизнес-аналитику нужно только проиллюстрировать проектную документацию, то выбор инструмента не принципиален - лишь бы можно было нарисовать с его помощью ту или иную диаграмму. Если же бизнес-аналитик должен не просто сделать иллюстрацию, а создать модель для последующего использования системными аналитиками, разработчиками и специалистами по тестированию на последующих этапах проекта, то выбор инструмента определяется его способностью к интеграции со средствами разработки, которые со значительной степенью вероятности будут использоваться в качестве инструментария реализации кода. Из наиболее технологически совершенных современных пар «средство разработки - средство моделирования» стоит отметить такие, как Visual Studio .NET - Rational XDE, Visual Studio .NET - Borland Together, Borland JBuilder - Borland Together.

Помимо текстовых редакторов и средств моделирования, бизнес-аналитики могут применять средства управления требованиями, позволяющие хранить структурированный и систематизированный список требований к продукту в какой-либо базе данных и обращаться к нему на последующих этапах, связывая требования с реализующими их составными частями продукта и тестами, проверяющими соответствие продукта требованиям, а также корректно отслеживать изменения в требованиях, которые возникают практически в каждом проекте, как бы тщательно ни проводилось исследование, и влияние этих изменений на результаты последующей работы. Из наиболее известных сегодня средств управления требованиями следует отметить RequisitePro (IBM/Rational), DOORS (Telelogic) и CaliberRM (Borland). Собственно, при надлежащей организации процесса разработки и при наличии необходимых шаблонов техническое задание можно сгенерировать с помощью средства управления требованиями и даже соблюсти при этом требования российских государственных стандартов.

Типичный интерфейс средства управления требованиями (Borland Caliber RM)

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

Проектирование

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

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

Какие инструменты применяются на этом этапе? Для создания диаграмм классов и диаграмм развертывания используются вышеперечисленные инструменты UML-моделирования. Для проектирования данных обычно применяют такие инструменты, как CA AllFusion Data Modeler (бывший ERwin), Sybase Power Designer, Oracle Designer, а также аналогичные инструменты компаний Embarcadero и Popkin Software. Для СУБД, разработанных компанией Microsoft, можно достаточно успешно применять и Microsoft Visio. Перечисленные инструменты позволяют создать как минимум скрипт для генерации базы данных, а различия между ними заключаются в способах управления генерацией серверного кода, связанного с созданием триггеров и хранимых процедур.

Отметим, что если инструменты 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 и некоторые другие компании.

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

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

На этапе разработки приложения средства моделирования тоже применяются, особенно в том случае, когда они могут осуществлять не только генерацию кода на различных языках программирования, но и поддерживать обратное проектирование, создавая диаграмму классов на основе готового приложения либо позволяя синхронно редактировать и код, и модель. Функция синхронного изменения кода и модели существенно упрощает многие процессы, сопровождающие собственно разработку, так что если есть возможность выбора инструментов, то стоит обратить внимание на ее поддержку (например, синхронное изменение кода и модели поддерживают некоторые редакции инструмента UML-моделирования Borland Together).

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

Тестирование и оценка качества

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

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

Основными производителями средств тестирования в настоящее время являются компании Compuware, Segue, Mercury Interactive, IBM/Rational, Borland. Каждая из них производит несколько инструментов автоматизированного тестирования, включая средства нагрузочного тестирования, проверки пользовательских интерфейсов, тестирования ошибок исполнения.

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

Если приложение предназначено для работы под управлением различных операционных систем и их языковых версий (например, разных 32-разрядных версий и редакций Microsoft Windows), то специалистам по тестированию могут пригодиться средства создания виртуальных машин, позволяющие иметь на одном компьютере несколько различных операционных систем, загруженных одновременно, и организовывать между ними сетевое взаимодействие (о продуктах данной категории мы планируем рассказать в отдельной статье). Из ПО такого класса широко распространены продукты компаний Microsoft и VMWare. При тестировании программ для установки приложений могут применяться также средства резервного копирования и восстановления образов жестких дисков, выпускаемые компаниями Symantec, PowerQuest и др.

Документирование

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

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

На основе руководства пользователя с помощью специальных инструментов обычно генерируются файлы справочной системы. В простейшем случае файл справочной системы можно создать с помощью Microsoft Word и утилит от Microsoft для создания help-файлов, включаемых в состав многих средств разработки, но при большом объеме работы нередко используются специализированные средства таких компаний, как Blue Sky Software, EC Software, JGsoft.

Внедрение и сопровождение

Перед внедрением продукта обычно создаются дистрибутивные приложения, облегчающие этот процесс, - именно их мы запускаем, устанавливая на компьютер тот или иной продукт. Для создания дистрибутивных приложения также применяются специализированные средства, лидерами рынка которых являются компании InstallShield Software и Wise Solutions. Нередко в состав средств разработки входят специализированные версии указанных продуктов, учитывающие их специфику (например, возможность включения в дистрибутив библиотек, входящих в состав данного средства разработки).

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

Коллективная разработка и управление проектом

Если над какой-либо частью проекта работает более одного человека, полезными при разработке могут оказаться средства контроля версий (наиболее популярными из них являются Merant PVCS Version Manager и Microsoft Visual SourceSafe). Нередко их применяют при создании не только кода приложения, но и документов (например, технического задания) либо моделей. В крупных проектах часто используются и средства управления изменениями. Подобные продукты позволяют хранить в единой базе данных все составные части проекта и их версии и упрощают управление версиями кода, моделей, требований, а также дают возможность отслеживать влияние изменений в одной части проекта на остальные его части. Из самых популярных сегодня средств управления изменениями следует отметить продукты компаний Borland и IBM/Rational.

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

Пример плана проекта разработки программного продукта (Microsoft Project)

Заключение

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

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

Этап 1: до середины 50-х .

Основные затраты связаны с кодированием (в машинных кодах). Появляются автокоды (языки с использованием мнемонических обозначений команд) и трансляторы с них (ассемблеры).

Реализуются возможности раздельной компиляции и перемещаемости программ. Появляются загрузчики и компоновщики программ.

Этап 2: середина 50-х – середина 60-х гг.

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

Fortran (1954-1957);

Algol-60 (1958-1960);

Cobol (1959-1961);

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

Этап 3: середина 60-х – начало 70-х гг.

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

Изменяется соотношение затрат на разработку ПО (40% и более тратится на отладку, проектирование и документирование), кодирование – один из самых простых видов работ. Используются и создаются "большие" языки программирования – ПЛ/1, АЛГОЛ-68, СИМУЛА-67, обобщающие и интегрирующие ранее найденные решения.

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

Этап 4 (“этап кризиса в развитии ПО”): начало 70-х–середина 70-х гг.

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

Получают признание методологии структурного программирования (Дейкстра, 1968г.), формируются основы технологии программирования (язык Паскаль (Н.Вирт), 1971г.).

Этап 5:1976г.– наше время. Этап посткризисного развития инструментальных средств.

1976г. – публикация работы Боэма, где вводится понятие жизненного цикла ПО и указывается, что основные затраты приходятся не на разработку, а на сопровождение программ.

Языки программирования:

C (начало 1970-х, впервые достаточно полно описан в 1978 г.);

Modula-2 (1978 г., развитие – язык Oberon (1988));

Prolog (1972 г., распространение получил с 1980 г.);

Smalltalk (1970-е годы, в 1980 был представлен как Smalltalk-80);

C++ (начало 1980-х гг., название – 1983, в привычном сегодня виде существует с 1990 г.);

Java (версия Java 1.0 – 1996 г., Java 2.0 – 1998, Java 5 – 2004...);

C# (1998–2001, версия 1.0 – 2000–2002, версия 2.0 – 2003-2005, версия 3.0 – 2004–2008, версия 4.0 – 2008–2010).

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

Контрольные вопросы:

1. Какие действия включает в себя разработка программного продукта?

2. Какие этапы в разработке программ выделяются в рамках Rational Unified Process (RUP)?

3. Что обеспечивает использование инструментальных средств?

4. Какие составные части входят в программу? Назначение каждой из частей.

5. Определения программы и программного обеспечения.

6. Какими свойствами должно обладать программное обеспечение?

7. Какие языки программирования применяют при разработке программ?

8. Определение инструментального программного обеспечения.

9. На какие четыре группыможно разбить инструментальное ПО? Примеры ПО для каждой группы.

10. По каким критериям можно сравнивать программы из одного класса?

11. Какие этапы выделяют в развитии инструментальных средств разработки ПО?

12. Назначение и основные характеристики компиляторов (ассемблеров) и редакторов связей.

13. Назначение и основные характеристикиредакторов текстов.

14. Назначение и основные характеристикиотладчиков.

15. Назначение и основные характеристикипрограмм создания инсталляторов.

16. Назначение и основные характеристикиредакторов ресурсов.

17. Назначение и основные характеристикипрофилировщиков.

18. Назначение и основные характеристикипрограмм поддержки версий.

19. Назначение и основные характеристикипрограмм создания файлов помощи (документации).

20. Назначение и основные характеристикигенераторов документации.

21. Назначение и основные характеристикидизассемблеров и декомпиляторов.

22. Назначение и основные характеристикипрограмм отслеживания активности системы и изменений, происходящих в системе.

23. Назначение и основные характеристикипрограмм-вериферов и контейнеров.

24. Назначение и основные характеристики программ для защиты разрабатываемого программного обеспечения (протекторов).

25. Назначение и основные характеристикиSDK.

26. Назначение и основные характеристики парсеров.

27. Назначение технологических стандартов.

ТЕМА: Методологии разработки ПО.

Литература: 1. Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения.

2. Гецци К., Джазайери М., Мандриоли Д. Основы инженерии программного обеспечения.

3. Камаев В. А., Костерин В. В. Технологии программирования.

Рассмотрим понятия методологии, метода и средства.

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

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

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

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

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

Методологии представляют собой ядро теории управления разработкой программного обеспечения.

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

Водопадные (каскадные);

Итерационные (спиральные).

Также существует и более общая классификация на:

Прогнозируемые;

Адаптивные.

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

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

Каскадная разработка или модель водопада (англ. waterfall model) - модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

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

Рис. 1. Каскадная модель жизненного цикла.

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

Преимущества применения каскадного способа:

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

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

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

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

Основным недостатком каскадной модели является существенное запаздывание с получением результатов и, как следствие, высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей. Это объяснятся двумя причинами:

Пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки;

За время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.

Рис. 2. Каскадная модель ЖЦ на практике.

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

Для преодоления перечисленных проблем в середине 80-х годов была предложена спиральная модель жизненного цикла (рис.3).

Рис. 3. Спиральная (итерационная) модель ЖЦ.

Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования .

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

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

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

Спиральная модель определяет четыре действия, представляемые отдельными секторами спирали:

1. Планирование - определение целей, вариантов и ограничений.

2. Анализ риска - анализ вариантов и распознавание/выбор риска.

3. Конструирование - разработка продукта следующего уровня.

4. Оценивание - оценка заказчиком текущих результатов конструирования.

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

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

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

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

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

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

Достоинства спиральной модели:

Наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

Позволяет явно учитывать риск на каждом витке эволюции разработки;

Включает шаг системного подхода в итерационную структуру разработки;

Использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки спиральной модели:

Новизна (отсутствует достаточная статистика эффективности модели);

Повышенные требования к заказчику;

Трудности контроля и управления временем разработки.

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

Rational Unified Process (RUP)

Гибкие методологии разработки (SCRUM, KANBAN, DSDM, MSF, ALM, XP)

Гибкая методология разработки (англ. Agile software development).

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

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

Одной из наиболее известных и передовых гибких методик является методология SCRUM.

SCRUM - методология, предназначенная для небольших команд (до 10 человек). Весь проект делится на итерации (спринты) продолжительностью 30 дней каждый. Выбирается список функций системы, которые планируется реализовать в течение следующего спринта. Самые важные условия - неизменность выбранных функций во время выполнения одной итерации и строгое соблюдение сроков выпуска очередного релиза, даже если к его выпуску не удастся реализовать весь запланированный функционал. Руководитель разработки проводит ежедневные 20 минутные совещания, которые так и называют - scrum, результатом которых является определение функции системы, реализованных за предыдущий день, возникшие сложности и план на следующий день. Такие совещания позволяют постоянно отслеживать ход проекта, быстро выявлять возникшие проблемы и оперативно на них реагировать.

KANBAN – гибкая методология разработки программного обеспечения, ориентированная на задачи.

Основные правила:

Визуализация разработки:

o разделение работы на задачи;

o использование отметок о положение задачи в разработке;

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

Измерение времени цикла (среднее время на выполнение одной задачи) и оптимизация процесса.

Преимущества KANBAN:

Уменьшение числа параллельно выполняемых задач значительно уменьшает время выполнения каждой отдельной задачи;

Быстрое выявление проблемных задач;

Вычисление времени на выполнение усредненной задачи.

DYNAMIC SYSTEM DEVELOPMENT METHOD (DSDM) появился в результате работы консорциума из 17 английских компаний. Целая организация занимается разработкой пособий по этой методологии, организацией учебных курсов, программ аккредитации и т.п. Кроме того, ценность DSDM имеет денежный эквивалент.

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

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

Базовые принципы, на которых строится DSDM:

Активное взаимодействие с пользователями;

Частые выпуски версий;

Самостоятельность разработчиков в принятии решений;

Тестирование в течение всего цикла работ.

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

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

Базовые концепции и принципы модели процессов MSF:

Единое видение проекта - все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат, всем должна быть понятна цель проекта;

Управление компромиссами - поиск компромиссов между ресурсами проекта, календарным графиком и реализуемыми возможностями;

Гибкость – готовность к изменяющимся проектным условиям;

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

Поощрение свободного общения внутри проекта;

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

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

Application Lifecycle Management (ALM) - разработанная и поддерживаемая компанией Borland.

Extreme Programming (XP) -экстремальное программирование, поддерживаемое открытым сообществом независимых разработчиков.

Предмет: Технология разработки программных продуктов.

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

Образовательная

Ознакомление с инструментальными средствами коллективной разработки ПО.

Развивающая:

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

Воспитательная:

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

Межпредметные связи:

Английский язык

Операционные системы

Информационные технологии

Основы алгоритмизации и программирования

Оборудование: доска, мел, письменные принадлежности, проектор, ПК

Тип урока: комбинированный

Метод обучения: Объяснительно иллюстративный

Ход урока:

1.Организационный момент

Проверка готовности кабинета

Объявление темы

2. Постановка цели урока

3.Повторение пройденного материала

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

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

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

Инструментальные среды программирования

4.Сообщение новых знаний

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

Инструментальные системы технологии программирования

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

5. Восприятие и осознание учащимися нового материала

6. Осмысление обобщение и систематизация знаний

7. Подведение итогов урока ипостановка домашнего задания

Выучить содержимое темы

Гагарина Л.Г. стр. С.257-259.

Ответить на вопросы:

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

Имеются некоторые трудности в выработке строгого определения CASE-технологии (компьютерной технологии разработки ПС). CASE - это абревиатура от английского Computer-Aided Software Engineering (Компьютерно-Помогаемая Инженерия Программирования). Но без помощи (поддержки) компьютера ПС уже давно не разрабатываются (используется хотя бы компилятор). В действительности, в это понятие вкладывается более узкий (специальный) смысл, который постепенно размывается (как это всегда бывает, когда какое-либо понятие не имеет строгого определения). Первоначально под CASE понималась инженерия ранних этапов разработки ПС (определение требований, разработка внешнего описания и архитектуры ПС) с использованием программной поддержки (программных инструментов). Теперь под CASE может пониматься и инженерия всего жизненного цикла ПС (включая и его сопровождение), но только в том случае, когда программы частично или полностью генерируются по документам, полученным на указанных ранних этапах разработки. В этом случае CASE-технология стала принципиально отличаться от ручной (традиционной) технологии разработки ПС: изменилось не только содержание технологических процессов, но и сама их совокупность.

В настоящее время компьютерную технологию разработки ПС можно характеризовать использованием

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

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

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

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

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

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

Рис. 16.3. Жизненный цикл программного средства для компьютерной технологии.

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

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

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

Генерация программ ПС. На этом этапе автоматически генерирует скелеты кодов программ ПС или полностью коды этих программ по формальным спецификациям ПС.

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

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

Аттестация ПС имеет прежнее содержание.

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

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

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

14.5. Инструментальные системы технологии программирования

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

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

• репозиторий,
• инструментарий,
• интерфейсы.

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

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

Самая общая архитектура инструментальных систем технологии программирования представлена на рис. 16.4.

Рис. 16.4. Общая архитектура инструментальных систем технологии программирования.

Различают два класса инструментальных систем технологии программирования: инструментальные системы поддержки проекта и языково-зависимые инструментальные системы.

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

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

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

Инструментальное программное обеспечение (Software tools) - программное обеспечение, используемое в ходеразработки, корректировки или развития других программ:

редакторы, компиляторы, отладчики, вспомогательные системныепрограммы, графические пакеты и др.

Сюда входят языки программирования, интегрированные среды разработки программ, CASE-системы и др.

7.1.2. Выбор языка программирования

Существующие на сегодняшний день языкипрограммирования можно выделить в следующие группы :

Универсальные языки высокого уровня;

Специализированные языки разработчика программного обеспечения;

Специализированные языки пользователя;

Языки низкого уровня.

В группе универсальных языков высокого уровня безусловным лидером на сегодня является язык C++. Действительно, он имеет ряд достоинств:

Масштабируемость. На языке C++ разрабатываютпрограммы для самых различных платформ и систем;

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

C++ имеет мощный препроцессор, унаследованный от С, но, как и любой другой мощный инструмент, требуетосторожного использования;

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

При этом язык C++ обладает рядом существенныхнедостатков:

Подключение интерфейса внешнего модуля через препроцессорную вставку заголовочного файла (#include)серьезно замедляет компиляцию при подключении большогоколичества модулей;

Недостаток информации о типах данных во времякомпиляции;

Сложность для изучения и компиляции;

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

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

поэтому пока альтернативы C++ нет . Для второстепенныхпроектов иногда используется Visual Basic. Язык Javaрассматривался как альтернатива Basic, но из-за отсутствия визуального

средства разработки форм он пока остается малопригодным.

Современный Object Pascal, как и Pascal, предложенный Н. Виртом в середине 70-х годов XX в., остается наиболее привлекательным для обучения основам программирования в силу своей

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

В нынешнее время в отличие от 60-х годов XX в. языкипрограммирования создаются крайне редко. За последние 15 лет можно отметить лишь две новинки, получившие широкоераспространение - это Java (Sun Microsystems, 1995 г.), ставшийпопулярным во многом благодаря технологии его использования в Интернете и появления такого понятия, как виртуальная Java-машина, и С# (Microsoft, 2000 г.), созданный на основе C++.

Создателем языка является сотрудник Microsoft Андреас Хейлсберг. Он стал известным в мире программистов задолго дотого, как пришел в Microsoft. Хейлсберг входил в число ведущих

разработчиков одной из самых популярных сред разработки - Delphi. В Microsoft он участвовал в создании версии Java - J++, так что опыта в написании языков и сред программирования ему не занимать. Как отмечал сам Андреас Хейлсберг, С# создавался как язык компонентного программирования, и в этом одно из главных достоинств языка, направленное на возможностьповторного использования созданных компонентов.

Другие достоинства языка С#:

Сохраняет лучшие черты популярных языковпрограммирования C/C++, на основе которых он создан. В связи с этим облегчается переход программистов от C++ к С#;

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

как указатели, адресация, разыменование, адреснаяарифметика;

Является полностью объектно-ориентированным языком, где даже типы, встроенные в язык, представлены классами;

Реализует возможности наследования и универсализации;

Учитывает все возможности Framework .Net, так как С# создавался параллельно с данной средой;

Благодаря каркасу Framework .Net, ставшему надстройкой над операционной системой, программисты С# получают те же преимущества работы с виртуальной машиной, что и

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

виртуальная Java-машина является интерпретатором байт-кода;

Мощная библиотека каркаса поддерживает удобствопостроения различных типов приложений на С#, позволяя легко строить Web-службы, другие виды компонентов,

достаточно просто сохранять и получать информацию из базы данных и других хранилищ данных;

Является источником надежного и эффективного кода.

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

Научные вычисления (языки C++, FORTRAN, Java);

Системное программирование (языки C++, Java);

Обработка информации (языки C++, COBOL, Java);

Искусственный интеллект (LISP, Prolog);

Издательская деятельность (Postscript, TeX);

Удаленная обработка информации (Perl, PHP, Java, C++);

Описание документов (HTML, XML).

С течением времени одни языки развивались, приобретали новые черты и остались востребованными, другие утратили свою актуальность и сегодня представляют в лучшем случае чистотеоретический интерес (Focal, PL/1 и др.). В значительной степени это связано с такими факторами:

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

Удобство сопровождения и тестирования программ;

Стоимость разработки с применением конкретного языка программирования;

Четкость и ортогональность конструкций языка;

Применение объектно-ориентированного подхода.

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

Языки баз данных;

Языки создания сетевых приложений;

Языки создания систем искусственного интеллекта и т. д.

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

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

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

В настоящее время языки типа ассемблера обычноиспользуют:

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

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

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

7.7.3. Выбор среды программирования

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

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

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

Обычно среда разработки предназначается для одногоопределенного языка программирования, как, например, Visual Basic или Deiphi, но существуют среды разработки, предназначенные для нескольких языков, такие как Eclipse или Microsoft Visual Studio.

Примеры сред разработки - Turbo Pascal, Borland C++, GNU toolchain, DrPython.

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

которых наиболее распространенные блоки программного кодапредставлены в виде графических объектов.

Наиболее часто используемыми являются визуальные среды Delphi, C++ Builder фирмы Borland (Inprise Corporation), Visual C++, Visual Basic фирмы Microsoft, Visual Ada фирмы IBM и др.

Большую популярность в наши дни получила технология.NET Framework, предложенная фирмой Microsoft в качестве платформы для создания как обычных программ, так ивеб-приложений. Основным преимуществом.NET являетсясовместимость различных служб, написанных на разных языках.

Например, служба, написанная на C++ для.NET, может обратиться к методу класса из библиотеки, написанной на Delphi; на С#можно написать класс, наследующий от класса, написанного на Visual Basic .NET, а исключение, выброшенное методом, написанным на С#, может быть поймано и обработано в Delphi.

Так же как и в случае с выбором языка программирования, выбор среды программирования определяется характеромпроекта, привычками и навыками разработчика, веяниями времени, требованиями заказчика и просто общественным мнением: «Все подобные разработки должны выполняться в среде...

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

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

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

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

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

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

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

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

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

4. Понятие компьютерной технологии разработки программных средств и ее рабочие места. Имеются некоторые трудности в выработке строгого определения CASE-технологии (компьютерной технологии разработки ПС). CASE - это абревиатура от английского Computer-Aided Software Engineering (Компьютерно. Помогаемая Инженерия Программирования). Но без помощи (поддержки) компьютера ПС уже давно не разрабатываются (используется хотя бы компилятор). В действительности, в это понятие вкладывается более узкий (специальный) смысл, который постепенно размывается (как это всегда бывает, когда какое-либо понятие не имеет строгого определения). Первоначально под CASE понималась инженерия ранних этапов разработки ПС (определение требований, разработка внешнего описания и архитектуры ПС) с использованием программной поддержки (программных инструментов). Теперь под CASE может пониматься и инженерия всего жизненного цикла ПС (включая и его сопровождение), но только в том случае, когда программы частично или полностью генерируются по документам, полученным на указанных ранних этапах разработки. В этом случае CASE-технология стала принципиально отличаться от ручной (традиционной) технологии разработки ПС: изменилось не только содержание технологических процессов, но и сама их совокупность.

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

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

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

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

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

Унифицированный язык моделирования UML Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. Унифицированный язык моделирования UML (Unified Modeling Language) – это преемник того поколения методов ООАП, которые появились в конце 80 -х и начале 90 -х гг.

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

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

UML выделяют следующие типы диаграмм: – диаграммы вариантов использования (usecase diagrams) – для моделирования бизнес-процессов организации (требований к системе); – диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними. На таких диаграммах показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования; – диаграммы поведения системы (behavior diagrams); диаграммы взаимодействия (interaction diagrams) – для моделирования процесса обмена сообщениями между объектами. – диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое.

– диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей. – диаграммы реализации (implementation diagrams): диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

Введение

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

Чтобы дать более полное представление о роли каждой утилиты или срезы разработки в процессе создания ПО, все рассмотренные в данном курсе лекций инструментальные средства будут рассмотрены на примере разработки приложений с использованием одного их высокоуровневых языков. Для простоты, все используемые инструментальные средства можно разделить на 4 группы. Рассмотрим подробнее каждую из групп.

Необходимые

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

§ редакторы текстов;

§ компиляторы и ассемблеры;

§ компоновщики или редакторы связей (linkers);

Часто используемые

Это средства, использования которых, в отличие от необходимых, можно избежать. Но без них процесс разработки весьма затрудняется и удлиняется; Из часто используемых средств стоит назвать:

§ утилиты автоматической сборки проекта;

§ отладчики;

§ программы создания инсталляторов;

§ редакторы ресурсов;

§ профилировщики;

§ программы поддержки версий;

§ программы создания файлов помощи (документации).

Специализированные

Эти инструментальные средства используются в исключительных случаях, решают довольно специфичные задачи:

§ программы отслеживания зависимостей;

§ дизассемблеры;

§ декомпиляторы;

§ hex-редакторы;

§ программы отслеживания активности системы и изменений, происходящих в системе;

§ программы-вериферы и контейнеры (создают виртуальную среду для отдельных классов программ, в которой можно исследовать поведение программы);

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

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

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

КЛАССИФИКАЦИЯ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ

ТЕМА 1 ПОНЯТИЕ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ.

КЛАССИФИКАЦИЯ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ.

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

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

· репозиторий,

· инструментарий,

· интерфейсы.

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

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

Самая общая архитектура инструментальных систем технологии программирования представлена на рис.

Рис. Общая архитектура инструментальных систем технологии программирования.

Различают два класса инструментальных систем технологии программирования: инструментальные системы поддержки проекта и языково-зависимые инструментальные системы.

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

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