1) Единая интерактивная оболочка.
2) Текстовый редактор (включая code completion — автоматическое завершение кода).
3) Система поддержки сборки (build), предназначается для компиляции проектов из исходных кодов, включающая компилятор с исходного реализуемого языка и компоновщик (linker) объектных бинарных кодов в единый исполняемый код (загрузочный модуль); компоновщик используется либо штатный, входящий в состав операционной системы, либо специфичный для данной среды;
- установить контрольную точку остановки;
- остановиться в заданной процедуры (методе);
- визуализировать значения переменных (или, на более низком уровне, регистров и областей памяти).
Некоторые компоненты и возможности современных IDE
Профилировщик (profiler) — инструмент для накопления и анализа статистических данных, полученных в результате исполнения программы под управлением интегрированной среды: число вызовов процедур (методов), объем памяти, используемой при выполнении программы, и т.д.
О важности технологии разработки
Инструменты анализа кода (code analysis) — его семантической корректности: отсутствие некоторых видов ошибок, обнаруживаемых обычно при исполнении, например, недостиживые условия; отсутствие необходимых проверок и полномочий безопасности и др. Эти возможности соответствуют духу и принципам надежных и безопасных вычислений (trustworthy computing), сформулированным в 2002 г. корпорацией Microsoft и последовательно воплощаемым этой фирмой в жизнь. Также в современные среды встраиваются инструменты анализа кода в терминах метрик (metrics), характеризующих его сложность, — например, цикломатическое число графа потоков управления в программе, степень сцепления (взаимосвязанности) классов и т.д.
- Рефакторинг (refactoring).
- Генератор тестов (unit test generator) — JUnit, NUnit.
- Система управления версиями исходных кодов (source code control system) — CVS, RCS, Mercurial, Visual SourceSafe.
- Инструменты поддержки командной разработки программ (teamwork) — Team Foundation Server (TFS), Visual Studio Online.
- Инструменты визуализации сгенерированного бинарного кода — ildasm (IL disassembler).
- Инструменты «запутывания» кода (obfuscation) — DotFuscator.
- Поддержка создания различных видов программных проектов (projects) и решений (solutions) на основе типовых шаблонов кода (code patterns); механизм разработки расширений (plug-ins, add-ins, add-ons).
- Поддержка моделирования структуры программ на языке моделирования UML (Unified Modeling Language). UML поддерживает разработку моделей деятельности при разработке программ и взаимодействия разработчиков между собой (activity diagrams).
Вопросы
- Сформулируйте определение интегрированной среды разработки программ.
- Каковы основные компоненты интегрированной среды?
- Назовите наиболее популярные интегрированные среды и их фирмы-разработчики.
- Какую функциональность обеспечивала среда Турбо-Паскаль?
- Что такое текстовый редактор?
- Какие дополнительный функции по синтаксической проверке вводимого исходного кода встроены в современные редакторы в интегрированной среде?
- Что такое сборка программ?
- Что такое отладчик и каковы его типовые команды?
- Какую функциональность обеспечивает поддержка коллективной разработки программ?
- Что такое Team Foundation Server?
- Что такое рефакторинг?
- Какие функции реализует поддержка моделирования программ на языке UML?
- Что такое обфускация и с какой целью она выполняется?
- Что такое моноязыковые и многоязыковые интегрированные среды?
Темы для курсовых работ, рефератов, эссе
- Краткий обзор концепции интегрированной среды разработки программ (реферат)
- Обзор истории интегрированных сред разработки программ (реферат)
- Турбо-среды фирмы Borland и их возможности (реферат)
- Возможности среды GNU Emacs (реферат)
- Обзор функциональности современных инт егрированных сред разработки программ (реферат)
Источник: devtype.blogspot.com
Тестировщик с нуля / Урок 7. Модели разработки ПО. Водопадная, итерационная и V-модель
Концепция современной интегрированной среды разработки приложений
Первоначально интегрированные среды разрабатывались для программирования на каком-либо одном исходном языке/ Например, среда Турбо- Паскаль — для программирования на расширении языка Паскаль фирмы Borland.
Однако постепенно проявилась тенденция к превращению таких моноязыковых интегрированных сред в многоязыковые, поскольку для разработки проектов на различных языках используются сходные принципы и механизмы и, кроме того, иногда удобно использовать в большим проекте фрагменты программы, написанные на разных языках. Например, хотелось бы использовать готовый унаследованный код (legacy code), написанный на более раннем языке (например, Си ), чтобы не переписывать его заново, например, на C#, с единственной целью включения в проект.
Например, широко известная интегрированная среда NetBeans первоначально создавалась как студенческий проект Карлова университета в Праге для программирования на языке Java . В настоящее время среда NetBeans развилась в мощную многоязыковую интегрированную среду, в которой реализована компонента C / C++ development pack, обеспечивающий поддержку разработки проектов на языках C и C++.
Отметим, что среда Visual Studio . NET с самого начала создавалась как многоязыковая среда. Это принципиальная установка фирмы Microsoft — дать возможность разработчикам выбрать наиболее удобный язык (или языки) для соответствующих частей разработанного проекта, а затем собрать проект из бинарных компонент (сборок — assemblies), полученных путем компиляции с соответствующих языков в единый бинарный промежуточный код CIL. Ниже мы еще раз рассмотрим подробнее эту удобную особенность Visual Studio и поддерживаемый ею набор языков.
1.6. Резюме
Интегрированная среда (integrated development environment — IDE) — набор инструментов для разработки и отладки программ, имеющий общую интерактивную графическую оболочку, поддерживающую выполнение всех основных функций жизненного цикла разработки программы.
Первыми интегрированными средами стали Турбо-среды фирмы Borland, GNU Emacs, среда программирования на языке Smalltalk. Интегрированные среды существенно повысили производительность программистов и обеспечили удобство разработки.
К числу возможностей современных интегрированных сред относятся: текстовый редактор (включая code completion — автоматическое завершение кода), система сборки бинарных кодов из исходных кодов, отладчик, профайлер, генератор unit-тестов, инструменты поддерждки коллективной разработки, инструменты связи с системой управления версиями, обфускатор, средства создания различных видов проектов и их визуализации, средства расширения функциональности и видов проектов (plug-ins); инструменты моделирования архитектуры проектов на языке UML .
Интегрированные среды могут быть моноязыковыми и многоязыковыми. Среда Visual Studio изначально является многоязыковой, а с версии 7 поддерживает платформу Microsoft. NET .
Ключевые термины
| Генератор тестов (unit test generator) | — инструмент для генерации типовых тестов для тестирования модулей (units) — методов или процедур — с различными возможными сочетаниями значений аргументов; типичные примеры — инструмент JUnit в интегрированных Java-средах и аналогичный инструмент NUnit в среде Visual Studio |
| Инструменты поддержки коллективной разработки программ (teamwork) | — инструменты поддержки этапов жизненного цикла программы (требования и спецификации, проектирование, реализация, тестирование), распределения заданий по разработке среди участников команды программистов, контроля выполнения заданий менеджером проекта. В среде Visual Studio такая компонента называлась сначала Team Foundation Server (TFS), а, начиная с версии Visual Studio 2013, она реализована в виде облачного интерфейса и получила название Visual Studio Online. |
| Интегрированная среда (integrated development environment — IDE) | — набор инструментов для разработки и отладки программ, имеющий общую интерактивную графическую оболочку, поддерживающую выполнение всех основных функций жизненного цикла разработки программы — набор и редактирование исходного текста (кода), компиляцию (сборку), исполнение, отладку, профилирование и др. |
| Набор инструментов (toolkit, toolbox) | — группа инструментов разработки программ, родственных по тематике и функциональности, но не объединенных в одну интегрированную интерактивную среду и вызываемых в командном режиме |
| Рефакторинг (refactoring) | — инструментарий систематических групповых модификаций программ в среде, без принципиальных изменений их функциональности, с целью улучшения кода. К типичным подобным действиям относится, например, изменение имени метода в его определении и во всех использованиях, добавление его аргумента, добавление try-catch — блока для обработки ранее не учтенного исключения и т.п. |
| Система поддержки сборки (build) | — инструментарий для компиляции проектов из исходных кодов, включающая компилятор с исходного реализуемого языка и компоновщик (linker) объектных бинарных кодов в единый исполняемый код (загрузочный модуль); компоновщик используется либо штатный, поставляемый вместо с ОС, либо специфичный для данной среды |
| Турбо-среды (Turbo Pascal, Turbo C, Turbo C++, Delphi и др.) | — интегрированные среды фирмы Borland для поддержки программирования на конкретных языках, реализованные сначала для операционной системы MS DOS, затем — для Windows |
| GNU Emacs | — многоязыковая и многоплатформная интегрированная среда разработки, реализованная для MS DOS, затем для Windows, OpenVMS и для Linux |
Краткие итоги
Интегрированная среда (integrated development environment — IDE) — набор инструментов для разработки и отладки программ, имеющий общую интерактивную графическую оболочку, поддерживающую выполнение всех основных функций жизненного цикла разработки программы.
Первыми интегрированными средами стали Турбо-среды формы Borland, GNU Emacs, среда программирования на языке Smalltalk. Интегрированные среды существенно повысили производительность программистов и обеспечили удобство разработки.
К числу возможностей современных интегрированных сред относятся: текстовый редактор (включая code completion — автоматическое завершение кода), система сборки бинарных кодов их исходных кодов, отладчик, профайлер, генератор unit-тестов, инструменты поддерждки коллективной разработки, инструменты связи с системой управления версиями, обфускатор, средства создания различных видов проектов и их визуализации, средства расширения функциональности и видов проектов (plug-ins); инструменты моделирования архитектуры проектов на языке UML .
Интегрированные среды могут быть моноязыковыми и многоязыковыми. Среда Visual Studio изначально является многоязыковой, а, начиная с версии 7, поддерживает платформу Microsoft. NET .
Набор для практики
Вопросы
- Сформулируйте определение интегрированной среды разработки программ.
- Каковы основные компоненты интегрированной среды?
- Назовите наиболее популярные интегрированные среды и их фирмы-разработчики.
- Какую функциональность обеспечивала среда Турбо-Паскаль?
- Что такое текстовый редактор?
- Какие дополнительный функции по синтаксической проверке вводимого исходного кода встроены в современные редакторы в интегрированной среде?
- Что такое сборка программ?
- Что такое отладчик и каковы его типовые команды?
- Какую функциональность обеспечивает поддержка коллективной разработки программ?
- Что такое Team Foundation Server?
- Что такое рефакторинг?
- Какие функции реализует поддержка моделирования программ на языке UML?
- Что такое обфускация и с какой целью она выполняется?
- Что такое моноязыковые и многоязыковые интегрированные среды?
Упражнения
Для данной вводной лекции упражнения не предусмотрены.
Темы для курсовых работ, рефератов, эссе
- Краткий обзор концепции интегрированной среды разработки программ (реферат)
- Обзор истории интегрированных сред разработки программ (реферат)
- Турбо-среды фирмы Borland и их возможности (реферат)
- Возможности среды GNU Emacs (реферат)
- Обзор функциональности современных инт егрированных сред разработки программ (реферат)
Дополнительные материалы, презентации
Презентация данной лекции доступна в файле VS_2013_Course_1.pptx.
Источник: intuit.ru
Особенности коллективной разработки ПО
Время, когда один-единственный программист мог вести весь проект целиком, безвозвратно прошло. Рынок наводнили акулы бизнеса, ожесточенно конкурирующие между собой, и требование к качеству продукта резко возросло. «Голая» программа без красивого графического интерфейса, многостраничной документации, официального сайта, службы поддержки уже никому не нужна. Исключение составляют утилиты, ориентированные на узкий круг профессионалов, которым достаточно развитого функционала, но таких — единицы и реальные деньги крутятся там, где обитают полуграмотные пользователи, популяция которых исчисляется сотнями миллионов.
Введение.
Модель группы и иерархическая модель
Обязанности членов группы
Модель проектной группы
Размеры группы и масштаб проекта
Крупные проекты
Тематические группы
Функциональные группы
Небольшие проекты
Поиск руководителей
Повышение эфективности коллективной работы
Вывод.
Файлы: 1 файл
Время, когда один-единственный программист мог вести весь проект целиком, безвозвратно прошло. Рынок наводнили акулы бизнеса, ожесточенно конкурирующие между собой, и требование к качеству продукта резко возросло. «Голая» программа без красивого графического интерфейса, многостраничной документации, официального сайта, службы поддержки уже никому не нужна.
Исключение составляют утилиты, ориентированные на узкий круг профессионалов, которым достаточно развитого функционала, но таких — единицы и реальные деньги крутятся там, где обитают полуграмотные пользователи, популяция которых исчисляется сотнями миллионов. Даже примитивный каталогизатор дисков, будучи достойно оформленным и поданным, может приносить неплохой доход, не говоря уже про автоматизацию предприятий или компьютерные игры. Было бы заманчиво написать такой продукт в одиночку, но увы. это практически невозможно. Даже гениальный программист, талантливый абсолютно во всем, навряд ли захочет отвечать на идиотские письма пользователей, а писем таких будет очень много и ведь каждый покупатель считает, что вместе с продуктом он покупает еще и внимание.
Десять лет назад можно было программировать, зная всего лишь Turbo Pascal и MS-DOS, теперь же количество обязательных языков/библиотек/технологий исчисляется десятками. Писать интерфейс на Си — это самоубийство, причем крайне болезненное и мучительное, но еще хуже пытаться реализовать вычислительное ядро на DELPHI. Поэтому неизбежно встает вопрос о создании команды, а может быть — и целой фирмы.
Работать в команде и сложно, и просто одновременно. С одной стороны, без обмена идей и знаний программист, находящийся в изоляции, никогда не сможет реализовать свой потенциал на 100%. Великие находки и грандиозные открытия, как правило, рождаются в спорах. С другой стороны, если ты один — тебе приходится рассчитывать только на самого себя и никто не придет на помощь в трудную минуту (про то, что некоторые пройдохи ухитряются перекладывать свои проблемы на чужие плечи, мы знаем, но скоромно промолчим).
Это были плюсы. Теперь о минусах. Командная работа требует намного большей самоотдачи, заставляя заниматься не тем, чем тебе интересно, а тем, что нужно команде (как говорится — «что полезно для вида, вредно для индивида»), при этом неудача одного из участников ударяет рикошетом по всем остальным и сотни часов, проведенных за монитором, летят впустую.
Сплоченные команды — большая редкость (если они вообще существуют в природе) и интересы участников чаще всего оказываются взаимно противоречивыми. Кто-то рвется вперед, выдвигая одну сумасбродную идею за другой, кто-то топчется на месте, вылизывая каждую строку кода и радуясь, что ему удалось сократить длину функции на шесть байт. Как следствие — возникают расколы и конфликты. Атмосфера внутри коллектива становится душной, а работа — непроизводительной.
Хуже всего приходится творчески активным индивидуалистам — необщительным, неуживчивым, неконтактным, привыкшим работать удаленно, каким, собственно, и является мышью, имеющий богатый опыт командной работы (хоть большей частью и отрицательный), но ведь. тут вот какой момент. Тот, кто умеет что-то делать неосознанно, кто наделен этим талантом от рождения, никогда не сможет объяснить — как именно и что именно он делает, почему поступает так, а не этак и т.д.
Модель группы и иерархическая модель
В настоящее время сложность промышленных приложений и систем такова, что процесс их разработки стал практически неуправляемым. Кроме того, их развертывание на сотнях компьютеров, расположенных в разных местах, значительно раздвигает границы процесса разработки.
Один человек не способен создать приложение масштаба предприятия. Ни один разработчик просто не удержит в голове все требования к системе и варианты проекта. Поэтому сегодня разработкой промышленных систем занимаются проектные группы, и все обязанности распределяются среди членов группы.
Существует две основные модели организации коллектива при разработке ПО:
1) иерархическая модель
2) модель группы
Работа в коллективе отличается определенными сложностями. Прежде всего, коллектив хочет знать «кто начальник». Ответ на этот вопрос дает иерархическая модель организации, определяющая начальников и подчиненных. Однако, если в современных производственных средах один менеджер проекта отвечает за все тонкости разработки и принимает все важные решения, возникает множество проблем, ведущих к провалу проекта. Иерархическая модель грешит множеством недостатков:
· невозможностью учесть все особенности проекта;
· отсутствием полноценной связи между всеми участниками проекта, так как вся информация идет в одном направлении — вверх по иерархии, к главному менеджеру;
· трудностью освоения новых технологий, необходимых при создании кроссплатформенных приложений;
· сложностью расстановки приоритетов.
Кроме того, опыта одного человека чаще всего недостаточно для быстрого решения задачи и для интеграции приложения в существующую инфраструктуру.
В организациях, построенных на основе иерархической модели, затруднен обмен информацией — в этой модели он, по определению, осуществляется через посредников. Вся информация иерархических групп « фильтруется» тремя или четырьмя менеджерами, что значительно повышает вероятность утери самого важного. Часто такое отсеивание идей происходит при прохождении сообщения от разработчика, непосредственно занимающегося проектом, к высшему руководству. Естественно, некоторые участники «выпадают» из процесса, что снижает эффективность их труда и повышает вероятность провала проекта.
Дабы сгладить недостатки иерархической модели, в проектной группе предусматривается распределение обязанностей руководителя между членами коллектива. При этом за проект отвечает не один человек, а все члены группы — каждый за свой участок.
Модель группы не определяет структуру коллектива с точки зрения отдела кадров. Ведь в такую разностороннюю группу привлечены ресурсы из разных отделов организации. Задача модели проектной группы — определить цели проекта и распределить обязанности. Руководители каждого направления с помощью выделенных им ресурсов выполняют возложенную на них часть работы.
Обязанности ролей определяются работой над проектом, а не деятельностью «штатной единицы». При этом руководители направлений выполняют свои обычные функции: составляют график выплаты премий, распределяют отпуска и контролируют эффективность работы сотрудников. Начальник может оценить степень участия и эффективность работы сотрудников в проектной группе, но это — прерогатива менеджера конкретного сотрудника, а не проектной группы.
И у коллективного подхода есть недостатки:
· разрозненная связь с внешними источниками информации;
· несогласованное представление о разных сторонах проекта;
· несогласованность личных планов членов группы;
· отсутствие опыта, снижающее эффективность коллективной работы.
Обязанности членов группы
MSF — не готовое решение, а каркас, который можно адаптировать для нужд любой организации. Один из элементов этого каркаса — модель проектной группы. Она описывает структуру группы и принципы, которым надо следовать для успешного выполнения проекта.
Хотя модель группы разработчиков весьма конкретна, при знаков знакомстве с MSF ее нужно рассматривать в качестве отправной точки. Разные коллективы реализуют этот каркас по-разному, в зависимости от масштаба проекта, размеров группы и уровня подготовки ее членов.
Чтобы проект считался удачным, следует решить определенные
задачи: I
· удовлетворить требования заказчика — проект должен выполнить
требования заказчиков и пользователей, иначе ни о каком успехе
не может быть и речи, возможна ситуация, когда бюджет и график
соблюдены, но проект провалился, так как не выполнены требования заказчика;
· соблюсти ограничения — разработчики проекта должны уложиться
в финансовые и временные рамки;
· выполнить спецификации, основанные на требованиях пользователей — спецификации — это подробное описание продукта, создаваемое группой для заказчика; они представляют собой соглашение между проектной группой и клиентом и регулируют вопросы, касающиеся приложения, в основе этого требования лежит принцип «сделать все, что обещано»;
· выпустить продукт только после выявления и устранения всех проблем — не существует программ без дефектов, однако группа должна найти и устранить их до выпуска продукта в свет, причем устранением ошибки считается не только ее исправление, но и, например, занесение в документацию способа ее обхода; даже такой способ устранения проблем предпочтительнее, чем выпуск приложения, содержащего не выявленные ошибки, которые в любой момент могут преподнести неприятный сюрприз пользователям и разработчикам;
· повысить эффективность труда пользователей — новый продукт должен упрощать работу пользователей и делать ее более эффективной. Поэтому приложение, обладающее массой возможностей применять которые сложно или неудобно, считается провальным;
· гарантировать простоту развертывания и управления — эффективность развертывания непосредственно влияет на оценку пользователем качества продукта, например, ошибка в программе установки может создать у пользователей впечатление, что и само приложение небезгрешно, от проектной группы требуется не только подготовить продукт к развертыванию и гладко провести его, но и обеспечить пользователей поддержкой, организовав сопровождение приложения.
Примечание. На проект влияет множество факторов, некоторые из которых создают дополнительные ограничения. Когда проектная группа рассматривает на совещаниях цели проекта и график его создания и выпуска, следует убедиться, что проект окупится, то есть удастся выпустить нужный продукт, не превышая запланированных расходов.
Для достижения этих целей в модели проектной группы выполняемые задачи распределяются по шести ролям: менеджмент продукта, менеджмент программы, разработка, тестирование, обучение пользователей и логистика. Люди, выполняющие конкретную роль, должны рассматривать проект со своей «колокольни» и обладать необходимой для этого квалификацией.
Шесть ролей модели проектной группы, подробно описанные в этой главе, связаны с шестью целями проектной группы, что проиллюстрировано в таблице. Все эти цели важны для успеха проекта в целом, и поэтому все роли равноправны. В этой модели нет руководителя всего проекта — есть группа людей, знающих, что нужно делать и делающих это.
Как же начать работу над проектом, не зная, сколько времени на это потребуется, сколько проект будет стоить и каких результатов ожидать? Обе эти модели предлагают составлять расписания и графики «снизу — вверх», в проектировании придерживаться подхода «сверху — вниз» и, кроме этого, распределять ответственность за результаты работы между членами группы. На первый взгляд может показаться, что эти рекомендации не отвечают на поставленный вопрос. Однако на самом деле они позволяют сократить риски на ранних стадиях проекта. Приняв на этих стадиях правильное решение, вы избежите серьезных изменений в дальнейшем, что намного сократит время выполнения проекта и затраты на него.
Модель проектной группы
Работа над проектом включает множество разных видов деятельности и изучение требований с разных точек зрения, поэтому распределение основных задач по нескольким ролям повышает шансы на успех проекта. Как видно из рисунка, в MSF определены шесть таких ролей, которые и составляют модель проектной группы. У каждой из ролей свои обязанности, выполнение которых и обуславливает удачу проекта.
Обычно каждую роль исполняют несколько человек, один из которых считается руководителем, именно он на совещаниях с другими членами группы представляет свое направление.
В проектную группу должны входить:
· инициативные сотрудники, способные принимать решения и нести ответственность за свое направление работы.
Источник: www.yaneuch.ru