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

Основные понятия ПИ: программа во всех ее проявлениях (состояниях) на этапах ЖЦ, а также методы, средства и инструменты ее изготовления.

Программа — это объект разработки, который не является осязаемым (нельзя пощупать, взвесить и т. п.) человеком, а доступен пониманию ЭВМ, для которой написан. Готовая программа — это программный продукт, реализующий определённые функции (задачи) ПрО, процесс проектирования и разработка которого осуществляется соответствующими программными методами, средствами и инструментами ТП.

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

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

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

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

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

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

В качестве аппарата задания начального состояния объекта используются языки спецификации (SADT, PSA, PSI, и т. д.), а для задания промежуточных состояний применяются ЯП и языки DLL, API и др.

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

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

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

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

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

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

Несмотря на различие этих методов в стратегиях проектирования, общее, что их объединяет — это модульное или блочное (программное) представление объекта разработки. Суть метода модульного программирования состоит в декомпозиции находкой задачи ПрО на отдельные функции, вплоть до элементарных, каждой из которых в общем случае сопоставляется программа или модуль. Каждый модуль должен обладать интерфейсом для его связи с другими модулями и компонентами. Применение данного метода предоставляет по сравнению с другими значительные преимущества в плане организации и управления разработкой, но вместе с тем требует создания определенных механизмов языкового и программного характера для решения проблем интерфейса при сборке модулей в более сложные программные структуры. Расширением данного метода является метод сборочного программирования, обеспечивающий сборку программных компонентов различной степени сложности [5−7].

Таким образом, указанные методы проектирования и программирования взаимосвязаны, они используют друг друга. Так, при применении восходящего метода проектирования для систем обработки данных на ранних этапах ЖЦ программного объекта применяются методы модульного программирования, расширения ядра и др.

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

Для реализации набора типовых функций автоматизируемой ПрО, относящейся к СОД, АСНИ, САПР и др., используются типовые технологические процессы (ТП), которые вместе со специализированными образуют линию программ в технологии функционально-ориентированного типа [8−11].

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

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

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

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

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

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

Управление разработкой. Каждая инженерная дисциплина базируется на принципах и методах конструирования (разработки) и промышленного производства продуктов, которые затрагивают как организационные, гак и технические аспекты производства. Основными вопросами управления разработкой программных объектов как инженерии ведения разработки являются [9−10]:

• 1) организация коллектива разработчиков (состав, структура, квалификация и др.);
• 2) планирование работ и трудозатрат и обеспечение роста производительности труда;
• 3) контроль хода разработки и оценка проектных решений в ходе разработки программных продуктов;
• 4) экономические вопросы (стоимость, ценообразование, стимулирование и др.);
• 5) управление качеством.

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

С ЖЦ связаны сроки и период разработки и эксплуатации ПС.

По срокам эксплуатации Г1С разделяются на два класса:

• 1) с краткосрочной эксплуатацией;
• 2) с долгосрочной эксплуатацией.

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

Программным объектам второго класса соответствуют регламентированные процессы проектирования, разработки и эксплуатации. Они создаются в проектных и промышленных организациях, занимающихся реализацией на ЭВМ крупных народнохозяйственных задач. Объекты данного класса изменятся в диапазоне 100−110 команд (операций Ассемблера) со свойством изменяемости и модификация при сопряжении и использовании. Такие объекты тиражируются и вместе с документацией передаются потребителю, отчуждаясь тем самым от разработчика. Срок жизни таких программ 10—20 лет, 70−80% этого срока приходится на эксплуатацию и сопровождение.

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

ТЛ ориентированы на производства ПП, требующее технико-экономическое обоснование процессов разработки, достижения высокого качества ПС, методов оценивания стоимости ПС и учета человеческого фактора в процессе разработки ПС [11].

Предложенная Боемом в [ 12] модель стоимости (СОСОМО) позволяет провести оценку на этапах ЖЦ с учётом ряда стоимостных атрибутов, квалификации исполнителей, степени использования современных методов программирования.

Основные элементы этой модели:

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

Модель жизненного цикла ПС. Процесс разработки ПС определяется моделью ЖЦ, этапы которой будем отождествлять с ТП. Для каждого ТП рассматриваемого ПС фиксируются его начальное (So), и промежуточные (S,) и конечное (Sr) состояния. Переход объекта из состояния S, в Sj+t из ТП, обеспечивается выполнением операций ТО, входящих в этот ТП. При этом для каждого типа ПС может быть свой набор ТП и состояний S, определяемых на соответствующем множестве исходных данных, характеризующих эти состояния [11]. Фактически формировался процессный подход к разработке ПП.

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

Основная цель выделяемых ТП|СТЛ состоит в получении некоторого полуфабриката ПП (Si — состояние ПС), фрагментов ЭПД для проведения экспертизы уровня и качества в соответствии с моделью качества М_кач. Каждый ТП модели ЖЦ в общем виде определяет состояние элементов ПС, состав технологических операций, обеспечивающих преобразование исходного состояния Г1С и получение его конечного состояния. Таким образом, общая технологическая модель (схема) процесса разработки является отражением модели ЖЦ, способов преобразования состояний ПС и представлена в виде.

Множество состояний S рассматриваемой модели включает в себя: S₀ — исходное (начальное) состояние — описание требований заказчика, предъявляемых к ПС; 5| - состояние, включающее в себя набор элементарных состояний, а именно, описаний функций (5]'), архитектуры (Sr), структуры данных (Si³) и т. п. средствами языков спецификаций L Si — состояние соответствует техническому проекту и включает в себя описание в классе языков L₂ алгоритмов функции (5|²), данных (S₂²), интерфейсов (Si гипертекстов документации (SV*), оценочных элементов модели качества (S₂⁵) и др.; 5₃ — состояние соответствует рабочему проекту и включает в себя описание в ЯП (класс L₃) текстов программ (S3¹), модулей (Si), тестов (S3³) и т. п.; 5₄ — состояние соответствует отлаженным элементам программного продукта; S₅ - состояние ПС после сборки; 5₆ — состояние ПС, соответствующее программному продукту, которое испытывается, проверяется на соответствие заданным функциям и значениям показателей качества; 5₇ — состояние ПС в процессе сопровождения.

Технологический процесс, входящий в состав М_пр — промежуточный (частичный) процесс, осуществляет преобразование S-го состояния ПС с помощью набора TOyCzTHj данной М"_р, поддерживаемых ТМ, (либо один ТМ реализует несколько ТО).

Набор операций М_пр не является фиксированным, он уточняется для каждого типа Г1С и описывается в технологических документах. Среди операций могут быть типовые, используемые готовыми при создании конкретной технологии разработки ПС определенного типа. Для обеспечения технологичности разработки в их состав входят операции управления качеством разработки и формирования документации на всех процессах ЖЦ в соответствии с системой моделей документации М_тд, определенной выше.

Модель общего вида любого частичного ТП| представлена на рис. 1.1.

Рис. 1.1. Модель ТП; процесса.

Состояние объекта S, определяется набором частичных его состояний S',…, 5*, подаваемых на вход ТП, = {ТО^}. Данный набор для конкретного ПС конечен.

Управление процессом преобразования состояний объекта 5₀ в S* может быть задано в виде графовой модели (соответствует технологическому маршруту), в вершинах которой находятся процессы (или операции), а ребра задают всевозможные переходы из одного состояния объекта в другое. Графовая модель отображает способ ведения разработки с распараллеливанием работ и возвратами (при ошибках) в предыдущие процессы (рис. 1.2).

Рис. 1.2. Графовая модель технологического процесса.

Каждый частичный процесс ТП, является абстрактным конечным автоматом, граф которого совпадает с технологическим маршрутом процесса, множество состояний S, которого определено на совокупности операций {ТО,} с ТО данного процесса.

Переход объекта из состояния S, в состояние S_i+i может быть только под действием технологического маршрута и осуществляется технологическим диспетчером посредством выбора из множества операций процесса, зафиксированных в карте /-го процесса, очередной операции при условии, что результат предыдущей операции проанализирован и выполнен.

Задача выполнения /'-го процесса заключается в переводе автомата из некоторого промежуточного состояния объекта в другое S_i+ с выполнением операций преобразования, качественной или количественной оценки результата разработки объекта и формирования фрагментов ЭПД по М_Эпд-

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