Базовый термин для инструментальных средств программной инженерии – автоматизированная программная инженерия (computer assisted software engineering – CASE). Однако практически смысл CASE-средств обычно ограничивается возможностями визуального моделирования для анализа и проектирования систем. Хотя большинство таких инструментальных средств имеет возможность прямого проектирования (формирование кода) и обратного проектирования (от существующего кода к визуальным моделям), они обычно не составляют законченную среду программирования. Инструментальное средство, которое всесторонне обеспечивает программиста, называется интегрированной средой разработки (integrated development environment – IDE).

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

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

· инструментальные средства моделирования систем (CASE);

· среды формирования ПО (IDE);

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

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

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

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

Управление проектом – нечто вроде распределения и управления бюджетом, временем и людьми. Главные вопросы здесь:

· Сколько будет стоить разработка системы?

· Сколько потребуется времени на разработку системы?

· Какие люди нам нужны для разработки системы?

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

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

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

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

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

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

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

4. Система ПО — просто часть намного большей информационной системы предприятия.

5. Процесс создания и эксплуатации ПО — часть бизнес-процесса. Результат процесса создания и эксплуатации ПО — ПО. Результат бизнес-процесса — бизнес.

6. В зависимости от того, для кого разрабатываются программные продукты (конкретного заказчика или рынка), программные продукты бывают двух типов: коробочные продукты (generic products – общие продукты или shrink-wrapped software – упакованное ПО) и заказные продукты (bespoke – сделанный на заказ или customized products – настроенный продукт). Важная разница между ними заключается в том, кто ставит задачу (определяет, или специфицирует требования). В первом случае это делают сами разработчики на основе анализа рынка (маркетинга) – и при этом рискуют сами. Во втором – заказчик, и при этом он рискует, что разработчик не сможет реально выполнить все требования в срок и при выделенном бюджете.

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

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

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

10. Системы ПО сложны. Сложность современного ПО заключается в «проводах» — в связях и коммуникационных путях между компонентами.

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

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

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

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

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

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

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

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

19. Имеются четыре главных представителя итеративных моделей: спиральная, Rational Unified Process (RUP), Model Driven Architecture (MDA) и модель быстрой разработки.

20. Спиральная модель – это на самом деле базовая метамодель, которая охватывает все итеративные модели. Модель состоит из четырех секторов жизненного цикла: планирование, анализ риска, инженерия и оценка проекта клиентом. Анализ рисков — наиболее характерная особенность спиральной модели.

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

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

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

24. UML (Unified Modeling Language — унифицированный язык моделирования) — стандартный язык моделирования для современных объектно-ориентированных систем ПО. Существуют различные расширения UML, известные как UML-профили, чтобы адаптировать UML к определенной предметной области и технологии.

25. Язык структурного моделирования в поддержку разработок, соответствующих функциональному подходу в старом стиле (глава 1), включает целый диапазон технологий визуализации, наиболее популярными из которых были диаграммы потока данных (data flow diagrams — DFD), диаграммы «сущность-отношение» (entity-relationship diagrams — ERD) и диаграммы структуры.

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

27. ERD — технология моделирования данных, которая широко используется за пределами структурного моделирования для представления структур БД. ERD строятся, используя два графических элемента: сущности и отношения. И сущности, и отношения могут содержать атрибуты.

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

29. Объектно-ориентированное UML-моделирование имеет дело с диаграммами классов, но в первую очередь определяется диаграммами сценариев использования. Модель сценариев использования — ориентир для всех других моделей. Другие модели обращаются к модели сценариев использования, чтобы выяснить требования пользователя и/или проверить, соответствуют ли они требованиям пользователя. Диаграммы классов представляют и состояние, и поведение системы. В конечном счете модели классов определяют главный подход к программированию.

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

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

32. Диаграммы взаимодействия — основная технология моделирования поведения (уровня проектирования) в UML. Они представляют передачу сообщений в системе. Имеются два вида диаграмм взаимодействия: диаграммы последовательности действий и диаграммы сотрудничества (связи).

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

34. Диаграмма деятельности — конечный автомат, который представляет выполняемые в системе вычисления. Как правило, диаграмма деятельности дополняет реализацию операций или сценарий использования.

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

36. Инструментальные средства программной инженерии принадлежат категории программных продуктов, известных как совместная автоматизированная разработка {computer-supported collaborative work — CSCW) или групповая вычислительная обработка (workgroup computing).

37. Инструментальные средства программной инженерии могут быть расклассифицированы на четыре группы: 1) инструментальные средства

38. управления проектами; 2) инструментальные средства моделирования систем (обычно известные как CASE-средства); 3) интегрированные среды разработки (IDE) и 4) инструментальные средства управления изменениями и конфигурацией.

39. Инструментальные средства управления проектами в основном связаны с планированием и управлением проектом. Однако современные средства дополнительно реализуют ряд связанных с этим функций или обеспечивают тесную интеграцию с используемыми инструментальными средствами. Эти функции — из области управления реализацией, сотрудничества на основе Web-технологий, информационного обеспечения, портфельного управления, обеспечения метрик и управления рисками.

40. Инструментальные средства моделирования систем охватывают все инструментальные средства, которые помогают инженерам ПО в задачах разработки — от анализа через проектирование к реализации. Все современные инструментальные средства поддерживают язык UML. Хотя они и способны сформировать код на основе моделей, они обычно все-таки не составляют полную среду программирования. Инструментальные средства моделирования систем сосредоточены на управлении требованиями и спецификациями, проектировании систем (включая моделирование БД), а также формировании отчетов и документов проекта.

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

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

Список литературы

1. Доррер Г.А. Методология программной инженерии. Учебное пособие /Г.А. Доррер – Красноярск: СибГУ, 2019. – 170 с.

2. Попов А.А., Доррер М.Г. Технология разработки ПО. Учебное пособие / А.А. Попов, М.Г. Доррер – Красноярск: СибГУ, 2019. – с.  

3. Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы / Ф. Брукс – М.: Символ-Плюс, 2010. — 304 с.

4. Липаев В. А. Программная инженерия. Основы методологии / В.А. Липаев – М.: Теис, 2006 - 609 с.

5. Батоврин В.К. Толковый словарь по системной и программной инженерии: учеб. пособие для вузов / В.К. Батоврин – М.: ДМК Пресс. 2012. – 280 с.

6. Орлик С. В. Введение в программную инженерию и управление жизненным циклом ПО / С.В.Орлик:URL : https://vk.com/sistemnaya_inzheneriya_levenchuk

7. Мацяшек Л.А. Практическая программная инженерия на основе учебного примера. Перевод с англ./ Л.А. Мацяшек, Б.Л. Лонг. – М. Бином. Лаборатория знаний, 2009, - 956 с.

8. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Перевод с англ. / Г. Буч, Д. Джекобсон – М.: ДМК, 2000. – 432 с.

9. Боэм Б.  Инженерное проектирование программного обеспечения / Б. Боэм – М.: Радио и связь, 1985. - 512 с.

10. Карпенко С. Н. Программная инженерия: назначение, основные принципы и понятия / С.Н. Карпенко – Н. Новгород: ННГУ, 2005. – 103 с.