ОСНОВЫ И ПРИНЦИПЫ ПРОГРАММНОЙ ИНЖЕНЕРИИ

Содержание:

ВВЕДЕНИЕ

Программная инженерия (промышленное программирование) обычно ассоциируется с разработкой больших и сложных программ коллективами разработчиков. Становление и развитие этой области деятельности было вызвано рядом проблем, связанных с высокой стоимостью программного обеспечения, сложностью его создания, необходимостью управления и прогнозирования процессов разработки. В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и заговорили о программной инженерии (или технологии промышленного программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ. С тех пор программная инженерия прошла достаточно бурное развитие. Этапы развития программной инженерии можно выделять по-разному. Каждый этап связан с появлением (или осознанием) очередной проблемы и нахождением путей и способов решения этой проблемы Сам термин – software engineering (программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике (г. Гармиш, Германия). Присутствовало 50 профессиональных разработчиков ПО из 11 стран. Рассматривались проблемы проектирования, разработки, распространения и поддержки программ. Там впервые и прозвучал термин «программная инженерия» как некоторая дисциплина, которую надо создавать и которой надо руководствоваться в решении перечисленных проблем. Вскоре после этого в Лондоне состоялась встреча 22-х руководителей проектов по разработке ПО. На встрече анализировались проблемы и перспективы развития ПО. Отмечалась возрастающее воздействие ПО на жизнь людей. Впервые серьезно заговорили о надвигающемся кризисе ПО. Применяющиеся принципы и методы разработки ПО требовали постоянного усовершенствования. Именно на этой встрече была предложена концепция жизненного цикла ПО (SLC – Software Lifetime Cycle) как последовательности шагов-стадий, которые необходимо выполнить в процессе создания и эксплуатации ПО.

1. ОБЩИЕ ПРИНЦИПЫ ПРОГРАММНОЙ ИНЖЕНЕРИИ: ЭФФЕКТИВНОСТЬ, ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ, НАДЕЖНОСТЬ, СТОЙКОСТЬ К ОШИБКАМ

Основные компоненты CS-науки: Computer Engineering (компьютерная инженерия), System Engineering (системная инженерия), Software Engineering (SE – программная инженерия), соответствующая ТП. Согласно энциклопедии СS (1992) приведем краткое определение этих инженерных дисциплин СS. Компьютерная инженерия – это теории, принципы и методы построения компьютеров (frameworks, суперкомпьютеров и т.п.), а также системного ПО ЭВМ (ОС, трансляторов, загрузчиков и т.д.). Системная инженерия – это теория, методы и принципы построения информационных систем, систем управления и Computer Systems. Программная инженерия – это система методов, способов и дисциплин планирования, разработки, эксплуатации и сопровождения ПО. Принципам и методам построения информационных систем (ИС) В.М. Глушков посвятил свой последний научный труд «Безбумажная информатика» (1982) [8]. В нем информационные системы – это компьютерные системы обработки информации на предприятиях, в органах управления и в производственной сфере. Базис таких систем – документы, не бумажные, а электронные, и система документооборота на всех уровнях управления государственных предприятий и органов. Информационные технологии (ИТ) – базис компьютерной инфраструктуры современных корпораций, предприятий и государственных органов управления, на которых главным источником деятельности является информация и решение различных задач обработки информации локального и глобального характера.

1.1 Основы и принципы программной инженерии

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

Частотный принцип - основан на выделении в алгоритмах и данных особых групп по частоте использования. Для действий, наиболее часто встречающихся при работе программ, создаются условия их быстрого выполнения. К часто используемым данным обеспечивается наиболее быстрый доступ. «Частые» операции стараются делать более короткими. Следует отметить, что лишь не более 5 % операторов программы оказывают ощутимое влияние на скорость выполнения программы. Этот факт позволяет значительную часть операторов программы кодировать без учета скорости вычислений, обращая основное внимание при этом на «красоту» и наглядность текстов.

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

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

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

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

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

1.2 Эффективность программной инженерии

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

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

● обследование объектов и среды проектирования для предварительной формализации целей, назначения и задач проекта;

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

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

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

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

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

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

1.2 Аспект: повторное использование

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

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

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

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

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

1.3 Надежность и стойкость к ошибкам в программной инженерии

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

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

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

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

• доступность (готовность) — относительное время работоспособного функционирования, измеряется как вероятность нахождения в работоспособном состоянии;

• соответствие— соответствие стандартам надежности.

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

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

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

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

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

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

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

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

Коэффициент готовности — вероятность иметь восстанавливаемую систему в работоспособном состоянии в произвольный момент времени.

Среднее время восстановления — математическое ожидание времени восстановления работоспособного состояния объекта после отказа.

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

ЗАКЛЮЧЕНИЕ

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

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

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

1. отсутствие производственной фазы в традиционном промышленном смысле;
2. Фаза сопровождения программного обеспечения в основном связана с продолжающейся его разработкой или эволюцией, а не с традиционным ремонтом и обслуживанием по причине физического износа.

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

Основанием программной инженерии является информатика, а не естественные науки, при этом основной упор делается на дискретную, а не на классическую (непрерывную) математику.

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

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

Электронные ресурсы

1. Принципы разработки программного обеспечения https://studwood.ru/1920236/informatika/printsipy_razrabotki_programmnogo_obespecheniya
2. Е.М. Лаврищева Программная инженерия: http://www.computer-museum.ru/books/lavrischeva_3_basics.pdf
3. С.Н. Карпенко Введение в программную инженерию: http://www.unn.ru/pages/issues/aids/2007/16.pdf
4. Построение гипермедиа систем — Информатика, программирование https://stud-baza.ru/postroenie-gipermedia-sistem-kursovaya-rabota-informatika-programmirovanie
5. Повторное использование: https://sprosi.pro/questions/57903/povtornoe-ispolzovanie-programmnogo-obespecheniya-isklyuchaet-vozmojnost-povtoryaemosti-protsessa
6. Программная_инженерия.Курс_лекций:http://repo.ssau.ru/bitstream/Uchebnye-izdaniya/Programmnaya-inzheneriya-Elektronnyi-resurs-elektron-uchebmetod-kompleks-po-discipline-v-LMS-Moodle-71103/1/Зеленко%20Л.%20С.%20Программная.pdf