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

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

1. Терминология

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

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

С учетом данного определения термин «Разработка программ» будет звучать следующим образом:

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

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

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

1. Проектирование приложения.
2. Реализация программного кода приложения.
3. Тестирование приложения.

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

2.1 Средства проектирования приложений

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

1. Анализ требований.
2. Разработка архитектуры будущего программного обеспечения.
3. Разработка устройств основных компонент программного обеспечения.
4. Разработка макетов Пользовательских интерфейсов.

Результатом проектирования обычно является «Эскизный проект» (Software Design Document) или «Технический проект» (Software Architecture Document). Задача «Анализ требований» обычно выполняется с использованием методов системологии (анализа и синтеза) с учетом экспертного опыта проектировщика. Результатом анализа обычно является содержательная или формализованная модель процесса функционирования программы. В зависимости от сложности процесса для построения данных моделей могут быть применены различные методы и вспомогательные средства. В общем случае для описания моделей обычно применяются следующие нотации (в скобках приведены программные средства, которые могут быть использованы для получения моделей):

• BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
• Блок-схемы (Vision 2003 и многие другие).
• ER-диаграмы (Visio 2003, ERWin, Sybase Power Designer и многие другие).
• UML-диаграмы (Sybase Power Designer, Rational Rose и многие другие).
• макеты, мат-модели и т.д.

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

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

• Функциональное программирование;
• Структурное программирование;
• Императивное программирование;
• Логическое программирование;
• Объектно-ориентированное программирование (прототипирование; использование классов; субъективно-ориентированное программирование).

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

• диаграмма классов и т.д (Ration Rose, Sybase PowerDisigner и многие другие).
• описание модулей структур и их программного интерфейса (например, Sybase PowerDisigner и многие другие).

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

2.2 Средства реализации программного кода

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

• языки программирования (C++,Си, Java, C#, php и многие другие);
• средства создания пользовательского интерфейса (MFC, WPF, QT, GTK+ и т.д.)
• средства управления версиями программного кода (cvs, svn, VSS).
• средства получения исполняемого кода (MS Visual Studio, gcc и многие другие).
• средства управления базами данных (Оracle, MS SQL, FireBird, MySQL и многие другие).
• отладчики (MS Visual Studio, gdb и т.д.).

2.3 Средства тестирования программ

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

• Тестирование на отказ и восстановление.
• Функциональное тестирование.
• Тестирование безопасности.
• Тестирование взаимодействия.
• Тестирование процесса установки.
• Тестирование удобства пользования.
• Конфигурационное тестирование.
• Нагрузочное тестирование.

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

• средства анализа кода, профилирования (Code Wizard – ParaSoft, Purify – Rational Softawre. Test Coverage – Semantic и т.д.);
• средства для тестирования функциональности (TEST – Parasoft, QACenter – Compuware, Borland SilkTest и т.д.);
• средства для тестирования производительности (QACenter Performance – Compuware и т.д).

3. Заключение

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

Также смотрите :

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

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

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

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

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

Процедурно-ориентированные и проблемно-ориентированные языки относятся к языкам высокого уровня, использующим макрокоманды. Макрокоманда при трансляции генерирует много машинных команд (для процедурноориентированного языка это соотношение в среднем "1 к десяткам машинных команд", а для проблемно-ориентированного – "1 к сотням машинных команд". Процедурноориентированные языки программирования являются самыми используемыми (Basic, Visual Basic, Pascal, Borland Delphi, С и др.). В этом случае программист должен описывать всю процедуру решения задачи, тогда как проблемно-ориентированные языки (их называют также непроцедурными) позволяют лишь формально идентифицировать проблему и указать состав, структуры представления и форматы входной и выходной информации для задачи.

При выполнении инструкций программ компьютеру необходимо преобразовать удобные для человеческого восприятия операторы, написанные на каком-либо языке программирования, в форму, попятную для компьютера. Инструментальное программное обеспечение имеет специальные программы, транслирующие (translate) текст программ, написанных на различных языках программирования, в машинные коды, которые затем выполняются компьютером. Этот вид программного обеспечения называется компилятором или интерпретатором. Текст программы, написанной на языке программирования высокого уровня, до того как быть преобразованным в машинные коды, называется исходным кодом (source code). Компилятор (compiler) преобразует исходный код в машинные коды, называемые объектным кодом (object code) – программой на выходном языке транслятора. Перед выполнением происходит процесс редактирования связей (linkage editing), заключающийся в том, что модули выходной программы объединяются с другими модулями объектного кода, содержащими, например, данные. Результирующий загрузочный модуль – это команды, непосредственно выполняемые компьютером. Некоторые языки программирования содержат не компилятор, а интерпретатор (interpreter), который преобразует каждое отдельное выражение исходного кода в машинные коды и сразу выполняет их. Интерпретатор удобен на этапе отладки программы, так как обеспечивает быструю обратную связь при обнаружении ошибки в исходном коде. Основы программирования на языке высокого уровня Visual Basic изложены в гл. 12 настоящего учебника.

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

Основные функции таких СУБД:

• управление данными во внешней памяти (на дисках);
• управление данными в оперативной памяти с использованием дискового кэша;
• фиксация изменений в специальных журналах, резервное копирование и восстановление базы данных после сбоев;
• поддержка языков БД (язык определения данных, язык манипулирования данными).

Теоретические основы СУБД описаны выше (параграф 3.2), а практическое применение описано в гл. 10.

Қазақстан Республикасының Министерство

Білім және ғылым образования и науки

министрлігі Республики Казахстан

Д. Серікбаев ат ындағы ВКГТУ

ШҚМТУ им. Д. Серикбаева

УТВЕРЖДАЮ

Декан ФИТиБ

М. Кылышканов

2015 г.

БАҒДАРЛАМАНЫ ӘЗІРЛЕУДІҢ ҚҰРАЛ-САЙМАНДАРЫ

Жұмыс модульдік оқу бағдарламасы және силлабус

ИНСТРУМЕНАЛЬНЫЕ СРЕДСТВА РАЗРАБОТКИ ПРОГРАММ

Количество кредитов дисциплины: 3

Усть-Каменогорск

Рабочая модульная учебная программа и силлабус разработаны на кафедре «Информационные системы и компьютерное моделирование» на основании Государственного общеобязательного стандарта образования РК ГОСО РК 5.04.019 - 2011 Высшее образование. Бакалавриат, Рабочего учебного плана, Типовой учебной программы и Модульной специальности.

Обсуждён на заседании кафедры «Информационные системы и компьютерное моделирование»

Зав. кафедрой Н. Денисова

Одобрен учебно – методическим советом ФИТиБ

Председатель Г. Уазырханова

Протокол № ____ от ____ ____________ 2015

Разработали

доцент кафедры Т. Балова

старший преподаватель кафедры И. Увалиева

Нормоконтролёр И. Фазылова

1 ХАРАКТЕРИСТИКА ДИСЦИПЛИНЫ, ЕЁ МЕСТО В УЧЕБНОМ ПРОЦЕССЕ

1.1 Краткое содержание изучаемой дисциплины

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

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

1.2 Цели и задачи изучения дисциплины

Цель изучения дисциплины «Инструментальные средства разработки программ» - ознакомление обучающихся с теоретическими знаниями в области технологий проектирования и обеспечения жизненного цикла программных систем, а также приобретение практических навыков использования современных технологий, ориентированных на моделирование бизнес-процессов и проектирование программных систем средствами CASE-технологий (Computer Aided Software/System Engineering, CASE). Цель дисциплины согласована с общими целями модульной образовательной программы специальности.

Компетентностный подход в преподавании дисциплины «Инструментальные средства разработки программ» определяет её основные задачи:

Сформировать у обучающихся систему знаний в области программной инженерии (Software engineering) и программирования (computer programming);

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

Выработать навыки применения CASE-средств структурного и объектно-ориентированного моделирования и проектирования программных средств.

Задачи изучения дисциплины обеспечивают реализацию установленных в квалификационной характеристике требований к подготовке бакалавров по образовательной программе 5В070400-«Вычислительная техника и программное обеспечение».

1.3 Результаты изучения дисциплины

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

знать и понимать:

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

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

Подходы к моделированию и реструктуризации бизнес-процессов и систем;

уметь применять на практике CASE-средства, поддерживающие:

Методологию функционального моделирования IDEF0;

Методологию событийного моделирования IDEF3;

Методологию моделирования потоков данных DFD;

Методологию семантического моделирования данных IDEF1X;

Методологию объектно-ориентированного моделирования программного обеспечения и метамодели UML;

быть готовым формировать суждения:

О выборе модели жизненного цикла для конкретного проекта и проекта;

По вопросам совершенствования программного обеспечения в рамках корпоративных информационных систем и крупных государственных проектов (от модели AS-IS к модели TO-BE);

О значении и последствиях своей профессиональной деятельности с учётом социальных, профессиональных и этических позиций;

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

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

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

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

Учебно-методическое обеспечение дисциплины направлено на успешное формирование указанных результатов обучения.

1.4 Пререквизиты

Для полноценного усвоения материала по дисциплине ИСРП необходимо наличие знаний по дисциплинам, связанным с алгоритмизацией и технологией программирования.

1.5 Постреквизиты

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

2.1 Тематический план

Наименование темы, её содержание	и другие источники	Трудоёмкость,
Модуль 1 «CASE-средства структурно-функционального проектирования программных средств»
Лекционные занятия
Тема 1 «Введение в дисциплину». Основные понятия. Классификация современных инструментальных средств разработки программных продуктов. Цель и задачи инструментальных средств разработки программ. История развития инструментальных средств.
Тема 2 «Методы проектирования программного обеспечения». Общие требования к методологии и технологии проектирования программного обеспечения. Руководство к своду знаний по программной инженерии SWEBOK. Обзор методов проектирования программного обеспечения. Обзор инструментария проектирования программного обеспечения
Тема 3 «Основы методологии проектирования программного обеспечения». Проектирование программ как сложных систем. Жизненный цикл программного обеспечения. Основные процессы ЖЦ ПО. Вспомогательные процессы ЖЦ ПО. Организационные процессы ЖЦ ПО
Тема 4 «Модели жизненного цикла программного обеспечения». Понятие модели жизненного цикла программного обеспечения. Классическая модель процесса разработки программ. Прототипирование. Стратегия инкрементальной разработки. Спиральная модель процесса. Модель быстрой разработки приложений RAD
Тема 5 «Методологии разработки программного обеспечения». XP - процесс или экстремальное программирование. Методология Rational Unified Process (RUP). Гибкие (agile) методологии. Выбор модели жизненного цикла для конкретного проекта. Порядок разработки программного обеспечения
Тема 6 «Современные CASE - технологии». CASE - технологии и их использование. Общая характеристика и классификация современных CASE-средств. Технологии внедрения и освоения CASE-средств. Оценка CASE-средств
Тема 7 «Моделирование бизнес-процессов». Понятие бизнес-процесса. Реструктуризация бизнес-процессов. Моделирование бизнес-процессов. Методы моделирования бизнес процессов
Тема 8 «CASE-технологии структурного анализа и проектирования программных средств». Методология структурного анализа и проектирования. Методология функционального моделирования IDEF0. Методология событийного моделирования IDEF3. Моделирование потоков данных DFD. Методология семантического моделирования данных IDEF1X
Лабораторные занятия
Тема 1 «Разработка функциональной модели IDEF0»
Тема 2 «Разработка моделей информационных процессов IDEF3 и потоков данных DFD»
Тема 3 «Методология семантического моделирования данных IDEF1X»
Тема 1 «Отчёты и Sibling диаграммы IDEF0-модели»
Тема 2 «Средства коллективной разработки функциональных моделей в среде BPwin»
Тема 3 «Создание отчётов в ERwin»
Тема 1 «Создание диаграмм FEO»
Тема 3 «Создание связи категоризации в IDEF1X-модели»
Итого по модулю 1
Модуль 2 «CASE-средства объектно-ориентированного проектирования программных средств»
Тема 9 «Основы объектно-ориентированного моделирования программного обеспечения и метамодели UML». Иерархия метаописаний, используемых в визуальном моделировании программного обеспечения. Назначение и уровни моделей UML. Представления в UML	21, 22, 23, 24, 25
Тема 10 «Унифицированный язык моделирования UML. Модель UML». UML – унифицированный язык моделирования. Сущности в UML. Отношения в UML	22, 23, 24, 25, 26, 27
Тема 11 «Унифицированный язык моделирования UML. Диаграммы UML». Виды диаграмм UML. Общие диаграммы UML. Специальные диаграммы UML	22, 23, 24, 25, 26, 27
Тема 12 «Унифицированный язык моделирования UML. Общие механизмы UML». Использование общих механизмов UML. Общие свойства модели. Точки семантики	22, 23, 24, 25, 26, 27
Тема 13 «Общее описание системы с позиции представления UML». Представления UML с позиции обобщения описаний. Общие механизмы UML. Общие свойства модели	22, 23, 24, 25, 26, 27
Тема 14 «Описание функциональности разработки программного обеспечения». Управление рисками проекта. Порядок разработки программного обеспечения. Документирование программных средств. Управление требованиями
Тема 15 «Научно-технологические тренды и самые быстрорастущие сегменты на мировом ИТ рынке». Три платформы в эволюции рынка ИТ. Новые тренды ИТ: прогноз компании Gartner. Мировые Top тренды развития ИТ на ближайшие 3-5 лет
Лабораторные занятия
	22, 23, 24, 25, 26, 27
	22, 23, 24, 25, 26, 27
	22, 23, 24, 25, 26, 27
Самостоятельная работа обучающегося под руководством преподавателя (СРОП)
Тема 4. «Построение структурных диаграмм UML»	22, 23, 24, 25, 26, 27
Тема 5. «Построение поведенческих диаграмм UML»	22, 23, 24, 25, 26, 27
Тема 6. «Генерация программного кода по модели UML»	22, 23, 24, 25, 26, 27
Самостоятельная работа обучающегося (СРО)
Тема 4. «Построение структурных диаграмм UML»	22, 23, 24, 25, 26, 27
Тема 5. «Построение поведенческих диаграмм UML»	22, 23, 24, 25, 26, 27
Тема 6. «Генерация программного кода по модели UML»	22, 23, 24, 25, 26, 27
Итого по модулю 2
Итого по дисциплине, кредит РК

2.2 Задания для самостоятельной работы (СРОП, СРО)

		Продолжитель-ность выполнения, уч. неделя	Форма контроля	Срок сдачи (номер уч. недели)
Задание на СРОП –IDEF0-модель дополнить отчётами и диаграммами Node Tree. Задание на СРО –IDEF0-модель дополнить диаграммой FEO.	Познакомиться с основными приёмами коллективной разработки функциональных моделей в среде BPwin		Инд. задание и дополнительные вопросы при защите . Тестовые задания
Задание на СРОП: Выполнить расщепление IDEF0-модели и ABC анализ. Задание на СРО – изучить элементы имитационной модели.	Получить практические навыки использования средств коллективной разработки модели с элементами анализа ABC
Задание на СРОП - для IDEF1X-модели построить шаблон отчёта. Задание на СРО – изучить работу по созданию связи категоризации в IDEF1X-модели	Изучить приёмы построения шаблонов отчёта средствами Report Builder среды ERwin и освоить процедуры работы со связями категоризации		Инд. задание и дополнительные вопросы при защите лабораторной работы Тестовые задания
Сенсорный многопозиционный ввод и события WPF	Получить начальные сведения о способах взаимодействия с приложением WPF с помощью касания экрана для интерактивного взаимодействия		Инд. задание и дополнительные вопросы при защите лабораторной работы. Тестовые задания
Триггеры свойств и событий WPF	Познакомиться с механизмом триггеров WPF для создания анимационного эффекта		Инд. задание и дополнительные вопросы при защите лабораторной работы. Тестовые задания
Использование API-интерфейса Office и первичных сборок. Net Microsoft. Office. Interop	Освоить упрощённый механизм взаимодействия с СОМ с целью расширения практических приёмов организации межпрограммного взаимодействия		Инд. задание и дополнительные вопросы при защите лабораторной работы. Тестовые задания

2.3 График выполнения и сдачи заданий по дисциплине

Основная литература

1 Рамбо Дж. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо - СПб.: Питер, 2002.-496 с.:ил.

2 CASE-технологии. Современные методы и средства проектирования информационных систем / - М.: Финансы и статистика, 1998.- 176 с.

3 Бахтизин, разработки программного обеспечения: учеб. пособие / , . - Минск: БГУИР, 2010. - 267 с. : ил.

4 , Анализ и компьютерное моделирование информационных процессов и систем / , .- Диалог-МИФИ, 2009. - 416 стр.

5 ISO/IEC 12207:2008. Systems and software engineering - Software life cycle processes [Электронный ресурс]. - URL: http://www. iso. org/iso/catalogue_detail? csnumber=43447, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

6 ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. – М. Изд-во стандартов, 2011., 115с.

7 ГОСТ Р ИСО/МЭК 11179-2-2012 Информационная технология. Регистры метаданных (РМД). Часть 2. Классификация [Электронный ресурс]. - URL: http:///Catalog/64/6430.shtml, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

8 ГОСТ Р ИСО/МЭК ТО 12182 – 2002. Информационная технология. Классификация программных средств. – Введ. 2002 – 06 – 11. – М. Изд-во стандартов, 2002

9 IEEE Computer Society. SWEBOK [Электронный ресурс]. - URL: http://puter. org/web/swebok, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

10 , Учебное пособие к практическим занятиям «Структурно-функциональный подход к проектированию и с использованием CASE-средств» / Перм. гос. тещн. ун.-т. – Пермь, 2005.- 245 с.

11 Марка МакГоуэн етодология структурного анализа и проектирования SADT [Пер. с англ.] / арка, акГоуэн - М.: МетаТехнология, 1993. -240 с.

12 РД 50.1.028-2001. Методология функционального моделирования IDEF0, Руководящий документ. Издание официальное. - М.: ИПК Издательство стандартов, 2000. - 75 с.

13 оделирование и анализ систем. IDEF-технологии: практикум/С. Черемных, И. Семенов, В. Ручкин.- М.: Финансы и статистика, 2006. -192 с.

14 , Структурный анализ систем. IDEF - технологии/С. Черемных, И. Семенов, В. Ручкин.- М.: Финансы и статистика,2001. – 208 с.

15 труктурные модели бизнеса: DFD-технологии/ А. Калашян, Г. Калянов.- М.: Прикладные информационные технологии, 2009.- 256 с.

Дополнительная литература

16 IEEE Std. 1320.2–1998. Стандарт IEEE по синтаксису и семантике языка концептуального моделирования IDEFIX97 (IDEF Object). - Введ. 1998-06-25. – Нью-Йорк: IEEE, 1998.

17 ффективное моделирование с AllFusion Process Modeler/ В. Дубейковский.- М.: Диалог-МИФИ, -2007.- 384 с.

18 оделирование бизнес-процессов с AllFusion Process Modeler/ С. Маклаков.- М.: Диалог-МИФИ, -2004.- 240 с.

19 BPwin и Erwin. CASE-средства для разработки информационных систем / С. Маклаков. - Диалог-МИФИ, 2000. - 320 с.

20 , Методология функционального проектирования IDEF0. Учебное пособие по курсу «Технология разработки программного обеспечения» для студ. спец. 40 01 01 Программное обеспечение информационных технологий дневной формы обучения. – Минск: БГУИР, 2003. – 24 с.: ил.

21 , Моделирование на UML. Теория, практика, видеокурс. - СПб, Профессиональная литература, Наука и Техника, 2010, 640 с.

22 зык UML. Руководство пользователя. Второе издание. - ДМК, 2006, 496 с.

23 Дж. Рамбо, М. Блаха, UML 2.0. Объектно-ориентированное моделирование и разработка.- Питер, 2007г., 544 с.

24 Мартин Фаулер. UML. Основы. Краткое руководство по стандартному языку объектного моделирования. Символ-Плюс, 2011., 192с.

25 The Unified Modeling Language (UML) [Электронный ресурс]. - URL: http://www. uml. org/, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

26 ведение в UML: [Электронный ресурс] - Открытые курсы Интернет-университета информационных технологий (ИНТУИТ). - Режим доступа http://www. intuit. ru/studies/courses/1007/229/info (дата обращения: 30.10.2015)

27 изуальное моделирование в среде IBM Rational Rose 2003: [Электронный ресурс] - Открытые курсы Интернет-университета информационных технологий (ИНТУИТ). - Режим доступа http://www. intuit. ru/studies/courses/14/14/info (дата обращения: 30.10.2015)

28 The Gartner Symposium/ITxpo [Электронный ресурс]. - URL: http://www. /technology/symposium/japan/exhibitor-directory. jsp, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

29 Обзор и оценка перспектив развития мирового и российского рынков ИТ / Блог компании Московская Биржа, IT-стандарты, ИТ-инфраструктура [Электронный ресурс]. - URL: http://habrahabr. ru/company/moex/blog/250463/, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

4 ОЦЕНКА ЗНАНИЙ

4.1 Требования преподавателя

Требования преподавателя:

Посещение лекционных и лабораторных занятий, СРСП по расписанию является обязательным;

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

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

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

В течение занятий мобильные телефоны должны быть отключены;

Студент обязан приходить на занятия в деловой одежде.

4.2 Критерии оценки

Оценка всех видов заданий осуществляется по 100-балльной системе.

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

Рубежный контроль знаний проводится на 7 и 15 неделе семестра в форме тестирования. Рейтинг складывается из следующих видов контроля:

Экзамен по дисциплине проходит во время экзаменационной сессии в форме тестирования.

Итоговая оценка знаний студента по дисциплине включает:

40% результата, полученного на экзамене;

60% результатов текущей успеваемости.

Формула подсчёта итоговой оценки:

где Р1, Р2 – цифровые эквиваленты оценок первого, второго рейтингов соответственно; Э – цифровой эквивалент оценки на экзамене.

Итоговая буквенная оценка и её цифровой эквивалент в баллах:

4.3 Материалы для итогового контроля

4.3.1 Модуль 1 «CASE-средства структурно-функционального проектирования программных средств»

В соответствии с международным стандартом ISO и IEC (International Electrotechnical Commission) технология программирования – это

A) один из видов деятельности, входящих в цикл разработки программного обеспечения

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

C) совокупность обобщённых и систематизированных знаний, или наука об оптимальных способах проведения процесса программирования, обеспечивающего в заданных условиях получение программной продукции с заданными свойствами

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

E) алгоритм, записанный на языке программирования

F) последовательность команд (операторов, инструкций) компьютера, выполнение которых приводит к получению результата решения задачи

Инструментальные программные средства (Software tools) – это:

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

B) программное обеспечение предприятий, функции которого обеспечивают финансовое управление, систему отношений с потребителями, управление кадрами и пр.

C) компоновщики и отладчики

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

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

Компилятор - это:

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

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

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

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

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

Основными преимуществами CASE-средств являются:

A) Увеличение затрат на разработку

B) Уменьшение затрат на разработку

C) Усложнение доступа к данным

D) Увеличение времени на разработку

E) Облегчение при модификации систем

F) Возможность хранения данных

В соответствии с проектом ICAM (Интеграция компьютерных и промышленных технологий) методология функционального моделирования производственной среды или системы связана с нотацией

К основным элементам IDEF3-модели относятся

B) связи (Links)

C) внешние сущности (external entities)

D) перекрёстки (Junctions)

E) потоки данных (data flow)

F) хранилища данных (data stores)

G) внешние сущности (external entities)

H) процессы или работы (activity)

4.3.2 Модуль 2 «CASE-средства объектно-ориентированного проектирования программных средств»

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

A) технического риска

B) календарного риска

C) управленческого риска

D) коммерческого риска

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

A) наследованием

B) инкапсуляцией

C) полиморфизмом

D) абстрагированием

E) многомодельностью

F) иерархическим построением

На диаграмме использования UML применяют следующие типы сущностей

B) Варианты использования

C) Действующие лица

D) Интерфейсы

F) Состояния

G) Объекты

Какая структурная сущность UML находится вне моделируемой системы и непосредственно взаимодействует с ней

A) класс (class)

B) интерфейс (interface)

C) действующее лицо (actor)

D) вариант использования (use case)

E) артефакт (artifact)

F) узел (node)

5 ОСНОВНЫЕ ФОРМЫ И МЕТОДЫ ОБУЧЕНИЯ

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

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

Интерактивная модель обучения, предусматривающая публичную защиту лабораторных работ в форме презентации, сообщения по теме СРОП и СРС;

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

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

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

Дистанционная технология обучения.

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

6 ВРЕМЯ КОНСУЛЬТАЦИЙ

Консультации проводятся по графику работы преподавателя.

Этап 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) -экстремальное программирование, поддерживаемое открытым сообществом независимых разработчиков.

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

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

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

CASE-средства. Характеристика современных CASE-средств

Обзор объектно-ориентированных инструментальных средств

Объектно-ориентированное программирование возникло раньше объектно-ориентированного анализа и проектирования, поэтому на сегодняшний день существует достаточно большое количество языков, поддерживающих данную технологию. Первым из них, по дате возникновения, считается язык Smalltalk , хотя многие элементы объектно-ориентированного подхода были использованы еще в языке Simula в 1967г. Наиболее мощным инструментом создания объектно-ориентированных программ на сегодня является язык C++ , созданный на базе языка структурного программирования C . Успешно развивается язык Java , который изначально разрабатывался как объектно-ориентированный.

Разработка крупных программных систем в современных условиях невозможна без использования средств автоматизации разработки программного обеспечения (CASE средств). CASE, поддерживающих объектно-ориентированный подход, не так много. Наиболее известное средство в этом направлении – система Rational Rose , которая поддерживает, в том числе, этапы объектно-ориентированного анализа и проектирования.

Объектно-ориентированное CASE средство Rational Rose

Разработчик Rational Rose - фирма Rational Software Corp., известная своими наработками в области объектно-ориентированных технологий, главной из которых является язык UML. Именно на поддержку UML, как основного языка проектирования ПО, и ориентированна данная CASE система.

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

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

Из основных возможностей можно перечислить следующие:

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

Удобная навигация между элементами модели при помощи "инспектора проекта".

Хранение результатов проектирования в виде единой модели.

Поддержка работы над проектом группы разработчиков.

Мощная система подготовки отчетов и документации о проекте.

Возможности синтеза программ практически на всех современных объектно-ориентированных языках, в том числе и на межплатформенном языке Java.

Поддержка компонентных технологий построения программных систем.

Широкие возможности по проектированию ПО различной архитектуры, от простых программ, до крупных "клиент-серверных" систем и Интернет-приложений.

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

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

Принципы разработки программных систем в Rational Rose

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

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

На всех этапах предоставляется возможность применять специализированные графические редакторы элементов модели и использовать инспектор модели для навигации среди ее компонентов. Вся проектная информация сохраняется в едином файле модели (*.mdl).

Работа начинается с построения диаграммы использования (Use Case Diagram), характеризующей основные задачи и окружение проектируемой системы. Далее, для каждого блока использования (Use Case), представленного на диаграмме использования, разрабатываются диаграммы последовательностей (Sequence Diagram), идентифицирующие объекты в системе и описывающие последовательности событий, возникающих в процессе общения объектов. Rational Rose позволяет автоматически связывать диаграммы последовательностей с блоками использования.

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

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

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

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

Проектирование программных средств

Моделирование предметной области . Создание проекта начинается с формирования принципов использования системы. В рамках Rational Rose это этап именуется "Use Case View". Реализация этого этапа позволяет идентифицировать внешних пользователей, блоки использования, объекты системы и связи между ними.

Составляется диаграмма использования, отражающая внешнее функционирование создаваемой системы. Эта модель во многом аналогична диаграмме потоков данных в структурном анализ. Основными ее составляющими являются внешние пользователи (actors), блоки использования (use case) и связи между компонентами. Для создания диаграммы в Rational Rose используется специализированный графический редактор.

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

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

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

Разработка логической структуры. После завершения формирования принципов использования системы, наступает этап разработки ее логической структуры. В Rational Rose он именуется "Logical View". Результатом данного этапа должна стать главная диаграмма, и детализирующие диаграммы для ее элементов.

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

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

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

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

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

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

Кроме диаграмм классов, для описания логики системы применяются на данном этапе применяются диаграммы состояний, диаграммы сценариев и другие элементы языка UML

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

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

Для визуализации компонентов проектируемой системы используются диаграммы компонент. Этап построения диаграмм компонент в Rose именуется "Component View". Он состоит из построения общей диаграммы и, при необходимости, детализации отдельных компонентов на вложенных диаграммах.

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

Построение диаграмм выполняется в специализированном редакторе. Для компонента задаются составляющие его классы.

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

Последним этапом в проектировании программного обеспечения является подготовка диаграммы развертывания. В Rose этот этап именуется "Deployment View". Диаграммы развертывания показывает конфигурацию исполняемой программной системы. Она состоит из узлов и отношений взаимодействия между узлами и компонентами. Узлы могут включать компоненты и объекты. Узлы являются физическими элементами времени выполнения.

Построение и сопровождение системы

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

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

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

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

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

Rational Rose 98 Enterprise Edition позволяет генерировать исходный текст на Visual Basic, C++, Java, а также получать описание интерфейсов компонент на языке IDL и создавать проекты для системы Oracle 8.

Реинжиниринг модели на основе исходных текстов . Возможность реинжиниринга, или, как его еще называют, "обратного проектирования", модели по исходным программным текстам представляется одной из важных и, безусловно, полезных функций Rose . Потребность в такой операции часто возникает при выполнении модификации и модернизации проекта. Сгенерированные по модели шаблоны программы, после их передачи программистам, могут быть модифицированы и необходимо учитывать эти изменения в модели. Кроме того, поскольку Rational Rose поддерживает импорт двоичных компонентов (COM объекты в среде Win32), то поддержка построения классов на основе описания интерфейсов двоичного компонента просто необходима.

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

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

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

Поддержка этапов разработки

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

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

Рабочие среды. Логичным развитием идеи использования шаблонов и внешних двоичных компонентов в Rational Rose стало появление рабочей среды (Framework).

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

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

Среда проектирования распределенных приложений (Application Performance Explorer)

Стандартная среда (Standard). Ориентированна на создание приложений на Visual Basic. Включает объявление многих стандартных объектов VB.

Среда проектирования приложений для Интернет (Internet). Включает определение различных компонентов ActiveX и библиотек VB.

Среда проектирования приложений для работы с локальными базами данных (Local Database). Содержит объявление объектов системы DAO

Среда проектирования приложений с использованием RDO (Remote Data Object). Позволяет использовать объекты RDO для создания клиент-серверных приложений.

Среда проектирования приложений для доступа к SQL-серверами (SQL Server Distributed Management Object (SQL-DMO)), поддерживающая доступ к SQL через объекты OLE-Automation.

Среда поддержки Microsoft Transaction Server

Среда поддержки Microsoft Outlook

Среды проектирования приложений на Java (Java JDK 114 Full и Java JDK 114 Quick). Включают модели классов и интерфейсов Java полученные путем реинжиниринга.

Среда поддержки Oracle8

Среда разработки назначается при создании модели. Хранятся среды разработки в виде файлов модели (*.mdl) предназначенных только для чтения (Read only). В процессе создания новой модели необходимые элементы загружаются из выбранной среды разработки, после чего новую модель.

Среды разработки представляют собой замечательный механизм для настройки Rose на конкретный проект. Можно создать собственную среду разработки, которая будет включать необходимые вам элементы из различных стандартных сред. В состав Rational Rose входит "мастер" по созданию рабочих сред.

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

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

Создаются различные рабочие области для разработчиков и рабочая область всего проекта. Каждый разработчик производит изменения в своей части (подмодели), и эти изменения становятся глобальными (переносятся в общую модель) только после их утверждения системой управления проектом. В качестве контроллеров проекта в Rose могут использоваться внешние системы, такие как ClearCase и Microsoft SourceSafe .

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

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

Добавление необходимых расширений обычно производится при начальной установки системы, однако их можно установить и позднее. Поддерживается распространение расширений через сеть Internet

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

Достоинства и недостатки Rational Rose

Данное CASE средство может быть применено для создания разнообразного объектно-ориентированного программного обеспечения, в первую очередь для платформы Windows, а так же на межплатформенном языке Java.

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

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

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