Методы программной инженерии

Методология и инструменты программной инженерии

Методология и инструменты программной инженерии

Молодяков С.А.

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

Программная инженерия — это область компьютерной науки и технологии, которая занимается построением программных систем… Это инженерная дисциплина, которая связана со всеми аспектами производства программного обеспечения (ПО) от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию. Термин – software engineering (программная инженерия) — впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике (г.Гармиш, Германия).

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

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

 Жизненный цикл ПО – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

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

Основными процессами (иногда называют этапами или фазами) жизненного цикла являются:

— Разработка спецификации требований (результат – описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать); — Разработка проекта программы (результат – описание того, как программа будет работать); — Кодирование (результат – исходный код и файлы конфигурации); — Тестирование программы (результат — контроль соответствия программы требованиям); — Документирование (результат – документация к программе);

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

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

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

во многом определяет успех проекта.

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

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

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

Наиболее известными стандартами программной инженерии являются: ·

ISO/IEC 12207 — Information Technology — Software Life Cycle Processes — Процессы жизненного цикла программных средств. Стандарт содержит определения основных понятий программной инженерии. (в частности программного продукта и жизненного цикла программного продукта).

SEI CMM — Capability Maturity Model (for Software) — модель зрелости процессов разработки программного обеспечения. Стандарт отвечает на вопрос: «Какими признаками должна обладать профессиональная организация по разработке ПО?». PMBOK — Project Management Body of Knowledge — Свод знаний по управлению проектами.

SWBOK — Software Engineering Body of Knowledge — Свод знаний по программной инженерии — содержит описания состава знаний по разделам (областям знаний) программной инженерии.

ACM/IEEE CC2001 — Computing Curricula 2001 – Академический образовательный стандарт в области компьютерных наук. Выделены 4 основных раздела компьютерных наук: Computer science, Computer engineering, Software engineering и Information systems, по каждому из которых описаны области знаний соответствующего раздела, состав и планы рекомендуемых курсов.

В настоящее время сообществом SWBOK разрабатывается расширенная версия знаний по программной инженерии, которая включает 15 областей:

• Software Requirements — требования к ПО.
• Software Design — проектирование ПО.
• Software Construction — конструирование ПО.
• oftware Testing — тестирование ПО.
• Software Maintenance — сопровождение ПО.
• Software Configuration Management — управление конфигурацией.
• Software Engineering Management — управление IT проектом.
• Software Engineering Process — процесс программной инженерии.
• Software Engineering Models and Methods — модели и методы разработки.
• Software Engineering Professional Practice — описание критериев профессионализма и компетентности.
• Software Quality — качество ПО.
• Software Engineering Economics — экономические аспекты разработки ПО.
• Computing Foundations — основы вычислительных технологий, применимых в разработке ПО.
• Mathematical Foundations — базовые математические концепции и понятия, применимые в разработке ПО.
• Engineering Foundations — основы инженерной деятельности.

Метод программной инженерии — это структурный подход к созданию ПО, который способствует производству высококачественного продукта эффективным в экономическом аспекте способом.

В этом определении есть две основные составляющие: (а) создание высококачественного продукта и (б) экономически эффективным способом.

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

Обычно выделяют три группы методов: эвристические методы (heuristic methods), касающиеся неформализованных подходов; формальные методы (formal methods), обоснованные математически; методы прототипирования (prototyping methods), базирующиеся на различных формах прототипирования.

Методология программной инженерии и стандарты регламентируют современные процессы управления проектами сложных систем и программных средств.

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

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

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

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

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

CASE (Computer-Aided Software Engineering) – набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов.

Инструменты (CASE) программной инженерии (Software Engineering Tools) [1]:

1.1. Инструменты работы с требованиями (Software Requirements Tools).

1.2. Инструменты проектирования (Software Design Tools) — инструменты для создания и проверки программного дизайна. (SADT/IDEF, UML, BPMN/BPEL, Microsoft DSL и т.п.)

1.3. Инструменты конструирования (Software Construction Tools) В соответствии с пониманием “конструирования”, заданным соответствующей областью знаний SWEBOK. Эти инструменты используются для производства и трансляции программного представления (например, исходного кода), достаточно детального и явного для машинного выполнения.

• Редакторы (program editors). Эти инструменты используются для создания и модификации программ и, возможно, ассоциированной с ними документации.
• Компиляторы и генераторы кода (compilers and code generators). Неинтерактивные (командные) трансляторы исходного кода. Компиляторы и редакторы в интегрированных средах программирования. К этому классу также относятся препроцессоры, линковщики/загрузчики, а также генераторы кода.
• Интерпретаторы (interpreters). Можно объединить интерпретаторы с компиляторами и генераторами кода, как средства непосредственной подготовки (трансляции) исходного кода к исполнению.
• Отладчики (debuggers). Эти инструменты поддерживают процесс конструирования программного обеспечения, но, в то же время, отличаются от редакторов и компиляторов.

1.4. Инструменты тестирования (Software Testing Tools)

• Генераторы тестов (test generators). Эти инструменты помогают в разработке сценариев тестирования.
• Средства выполнения тестов (test execution frameworks). Эти средства обеспечивают среду исполнения тестовых сценариев в контролируемом окружении, позволяющем отслеживать поведение объекта, подвергаемого тестированию.
• Инструменты оценки тестов (test evaluation tools). Эти инструменты поддерживают оценку результатов выполнения тестов, помогая определить в какой степени и где именно обнаруженное поведение соответствует ожидаемому поведению.
• Средства управления тестами (test management tools).
• Инструменты анализа производительности (performance analysis tools).

1.5. Инструменты сопровождения (Software Maintenance Tools) Эта тема охватывает инструменты, особенно важные для обеспечения сопровождения существующего программного обеспечения, подверженного модификациям:

• Инструменты облегчения понимания (comprehension tools). Эти инструменты помогают человеку в понимании программ. Примерами могут служить различные средства визуализации.
• Инструменты реинжиниринга (reengineering tools). Эти инструменты поддерживают деятельность по реинжинирингу, описанную в области знаний SWEBOK “Software Maintenance”.

1.6. Инструменты конфигурационного управления (Software Configuration Management Tools) Инструменты конфигурационного управления делятся на три категории:

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

1.7. Инструменты управления инженерной деятельностью (Software Engineering Management Tools) Средства управления деятельностью по программной инженерии делятся на три категории:

• Инструменты планирования и отслеживания проектов.
• Инструменты управления рисками.
• Инструменты количественной оценки.

1.8. Инструменты поддержки процессов (Software Engineering Process Tools):

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

1.9. Инструменты обеспечения качества (Software Quality Tools) Средства обеспечения качества делятся на две категории:

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

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

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

В заключение приведу слова Липаева В.В.

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

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

В публикации использованы открытые электронные материалы:

1. Орлик С., Булуя Ю. «Введение в программную инженерию и управление жизненным циклом» (базируется на SWEBOK). http://software-testing.ru/library/around-testing/engineering/267-swebok
2. Программная инженерия http://iibs.vvsu.ru/ispi/nap/pi/
3. Липаев В.В. Программная инженерия в жизненном цикле программных средств http://citforum.ru/SE/lipaev/

Источник: https://hsse.spbstu.ru/metodologiya_i_instrumentu_programmnoy_inzghenerii/

Методы программной инженерии

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

Модульное программирование

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

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

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

Ничего непонятно?

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

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

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

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

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

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

Структурное программирование

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

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

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

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

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

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

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

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

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

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

Каскадный и гибкие методы

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

Замечание 1

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

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

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

Рисунок 1. Каскадный метод. Автор24 — интернет-биржа студенческих работ

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

Источник: https://spravochnick.ru/informacionnye_tehnologii/metody_programmnoy_inzhenerii/

Инструменты и методы программной инженерии — Программирование

Источник: https://www.sites.google.com/site/opaisspo/instrumenty-i-metody-programmnoj-inzenerii

2. Методы программной инженерии (Software Engineering Methods)

Основы программной инженерии (по SWEBOK)

Программная инженерия. Инструменты и методы программной инженерии.

Инструменты инспектирования. Эти средства используются для поддержки обзора (review) и аудита.

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

1.10Дополнительные аспекты инструментального обеспечения (Miscellaneous Tool Issues)

Эта тема охватывает вопросы, касающиеся всех классов инструментов. Создателями SWEBOK идентифицированы три категории таких аспектов:

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

Мета-инструменты. Такие средства генерируют другие инструменты. Например, классическим примером мета-инструмента является компилятор компиляторов.

Оценка инструментов. Данная тема представляется достаточно важной в силу постоянной эволюции инструментов программной инженерии.

Данная секция (подобласть) разделена на три темы: эвристические методы (heuristic methods), касающиеся неформализованных подходов; формальные методы (formal methods), обоснованные математически; методы прототипирования (prototyping methods), базирующиеся на различных формах прототипирования. Эти три темы не являются изолированными , скорее они выделены исходя из их значимости и на основе определенных достаточно явных индивидуальных особенностей. Например, объектно-ориентированный подход может включать формальные техники и использовать прототипирование для проверки и аттестации. Так же как и инструменты, методы программной инженерии постоянно эволюционируют. Именно поэтому, в описании данной области знаний авторы SWEBOK постарались избежать, насколько это возможно, упоминания любых конкретных методологий.

2.1 Эвристические методы (Heuristic Methods)

Эта тема содержит четыре категории методов: структурные, ориентированные на данные,

объектно-ориентированные и ориентированные на область применения.

Структурные методы (structured methods). При таком подходе системы строится с

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

Методы, ориентированные на данные (data-oriented methods). Отправной точкой такого подхода являются структуры данных, которыми манипулирует создаваемое программное обеспечение. Функции в этом случае являются вторичными.

Объектно-ориентированные методы (object-oriented methods). Система при таком подходе рассматривается как коллекция объектов, а не функций.

Методы, ориентированные на конкретную область применения (domain-specific methods). Такие специализированные методы разрабатываются с учетом специфики решаемых задач, например, систем реального времени, безопасности (safety) и защищенности (security).

2.2Формальные методы (Formal Methods)

http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)

Программная инженерия. Инструменты и методы программной инженерии.

Эта тема касается математических (строгих) методов программной инженерии.

К сожалению, SWEBOK не дает здесь какого-либо определения формальных методов, поэтому, хотелось бы привести в данном контексте характеристику, данную им одним из классиков программной инженерии – Ианом Соммервиллем [Соммервилл, 2002, стр.

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

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

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

Эти методы можно классифицировать в виде следующих категорий:

Языки и нотации специфицирования (specification languages and notations). Языки спецификаций могут быть ориентированы на модель, свойства и поведение. По мнению автора, ярким примером такого рода методов являются формальные методы описания требований, интерес к которым периодически возникает на протяжении всей истории программной инженерии.

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

Подтверждение/доказательство (verification/proving properties). Этот подход основывается на строгом доказательстве точности характеристик с использованием теорем и проверки точности моделей.

История программной инженерии показала, что в области разработки прикладных систем, обоснованность (в частности, в силу трудоемкости) применения формальных методов не подтверждается на практике, за исключением случаев “скрытого” (неявного для разработчиков) применения определенных формальных методов на уровне внутренней реализации конкретных инструментов программной инженерии, например, в средствах моделирования и проектирования. Иан Соммервилл дает такую характеристику формальным методам [Соммервилл, 2002, стр. 188]: “Традиционные технические дисциплины … обычно легко адаптируют математические методы. Однако инженерия программного обеспечения не идет таким путем. Хотя прошло более 25 лет исследований по использованию математических методов в процессе создания ПО, воздействие этих методов все же ограничено. Так называемые формальны методы … широко не используются. Многие компании, разрабатывающие ПО, не считают экономически выгодным применение этих методов в процессе разработки.”

2.3 Методы прототипирования (Prototyping Methods)

Эта тема охватывает методы, основанные на прототипировании программного обеспечения. Они разделены на три категории:

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

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

http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)

Программная инженерия. Инструменты и методы программной инженерии.

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

http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)

Программная инженерия. Качество программного обеспечения.

Программная инженерия

Качество программного обеспечения

(Software Quality)

Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge — SWEBOK®, 2004.

Источник: https://studfile.net/preview/3652697/page:23/