Технология программирования билеты. тех прог билеты. Свойства алгоритма
 Скачать 14.94 Kb.
|
|
з11 Алгоритм — это последовательность действий для исполнителя, записанная на формальном языке и приводящая к заданной цели за конечное время. Алгоритм - описание конечной последовательности шагов в решении задачи, приводящей от исходных данных к требуемому результату. Свойства алгоритма – это набор свойств, отличающих алгоритм от любых предписаний и обеспечивающих его автоматическое исполнение. Алгоритм обладает следующим набором основных свойств: дискретностью, массовостью, формальностью, результативностью, определенностью. З12 На практике наиболее распространены следующие формы представления алгоритмов: словесная (записи на естественном языке); графическая (изображения из графических символов); псевдокоды (полуформализованные описания алгоритмов на условном алгоритмическом языке, включающие в себя элементы языка программирования и фразы естественного языка, общепринятые математические обозначения и др.); программная (тексты на языках программирования). З13 Программное обеспечение Системное(СПО) -базовое и сервисное Прикладное(ППО) - специализированное (делится на профессиональное и потребительское), Универсальное З14 ПО и развитие ПО напрямую зависимо от доступных технических средств. По сути развитие технических средств является ограничителем развития ПО. Выше способностей на вычисления не прыгнешь. З15 Развитие программных систем близко связано с развитием языков программирования. Там же и удобство. Чем более ПС развита, тем легче ей пользоваться. Интерфейс из консоли превращается в визуальный, количество требуемого кода для выполнения задачи уменьшается. З16 Существует три основных парадигмы: структурное, объектно-ориентированное и функциональное. Интересно, что сначала было открыто функциональное, потом объектно-ориентированное, и только потом структурное программирование, но применяться повсеместно на практике они стали в обратном порядке. Классификация языков программирования 1.Процедурные языки 2.Языки программирования низкого уровня 3.Языки программирования высокого уровня 4.Объектно-ориентированные языки 5.Декларативные языки программирования 6.Функциональные языки программирования 7.Логические языки программирования 8.Языки сценариев (скрипты) 9.Языки, ориентированные на данные З17 Простые программные системы - разрабатываются одним человеком. В случае необходимости внесения изменений проще создать систему заново. Сложные программные системы - имеют большое время жизни, и большое количество пользователей оказывается в зависимости от их нормального функционирования. З18 Программный продукт— комплекс взаимосвязанных программ для решения определенной проблемы (задачи) массового спроса, подготовленный к реализации как любой вид промышленной продукции. Как правило, программные продукты требуют сопровождения, которое осуществляется специализированными фирмами — распространителями программ (дистрибьюторами), реже — фирмами-разработчиками. З19 Ка́чество програ́ммного обеспечения — способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям. Стандарт ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015)[8] определяет модель качества продукта, которая включает восемь характеристик верхнего уровня: функциональная пригодность; уровень производительности; совместимость; удобство использования (юзабилити); надёжность; защищённость; сопровождаемость; переносимость (мобильность). З110 К сложной можно отнести систему, обладающую по крайней мере одним из ниже перечисленных признаков: систему можно разбить на подсистемы и изучать каждую из них отдельно; система функционирует в условиях существенной неопределённости и воздействия среды на неё, обусловливает случайный характер изменения её показателей; система осуществляет целенаправленный выбор своего поведения. З111 Технологией программирования называют совокупность методов и средств, используемых в процессе разработки программного обеспечения. Первый этап – «стихийное» программирование (от появления первых вычислительных машин до середины 60-х годов XX в). Первые программы имели простейшую структуру. Они состояли из собственно программы на машинном языке и обрабатываемых ею данных (рис. 1). Сложность программ в машинных кодах ограничивалась способностью программиста одновременно мысленно отслеживать последовательность выполняемых операций и местонахождение данных при программировании. Второй этап – структурный подход к программированию (60-70-е годы XX в.). В основе структурного подхода лежит декомпозиция (разбиение на части) сложных систем с целью последующей реализации в виде отдельных небольших (до 40-50 операторов) подпрограмм. При таком подходе задача представляется в виде иерархии подзадач простейшей структуры. Проектирование осуществляется «сверху вниз» и подразумевает реализацию общей идеи, обеспечивая проработку интерфейсов подпрограмм (нисходящее проектирование). Третий этап – объектный подход к программированию (с середины 80-х до конца 90-х годов ХХ века). Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений Четвертый этап – компонентный подход и CASE-технологии (с середины 90-х годов XX до нашего времени). Компонентный подход предполагает построение программного обеспечения из отдельных компонентов физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию. З112 Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации Модель жизненного цикла программного обеспечения — обобщенное описание действий и задач, осуществляемых в ходе разработки, внедрения и сопровождения информационной системы. Это абстракция реального процесса создания продукта, в которой опущены многие мелкие нюансы. Такое обобщение нужно, чтобы разработчикам было удобнее выбрать подходящую модель под свой проект, не запутавшись в несущественных деталях. З113 Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад») — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом в 1970 году. Каскадная модель с обратными связями Реализовать классическую каскадную модель ЖЦ в чистом виде затруднительно ввиду сложности разработки ПС без возвратов к предыдущим шагам и изменения их результатов для устранения возникающих проблем. В этой связи разработаны варианты каскадной модели с обратными связями между ее отдельными шагами. V-образная модель Основное назначение V-образной модели – обеспечение планирования тестирования (испытаний) системы и программного средства на ранних стадиях проекта. V-образная модель представляет собой разновидность каскадной модели. Данная модель поддерживает каскадную стратегию однократного выполнения этапов процесса разработки ПС или систем и базируется на предварительном полном формировании требований. В классической V-образной модели каждый шаг начинается после завершения предыдущего шага. З114 Спира́льная модель, предложенная Барри Боэмом в 1986 году, стала существенным прорывом в понимании природы разработки ПО. Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как итеративность, так и этапность. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков: Дефицит специалистов. Нереалистичные сроки и бюджет. Реализация несоответствующей функциональности. Разработка неправильного пользовательского интерфейса. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей. Непрекращающийся поток изменений. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. Недостаточная производительность получаемой системы. Разрыв между квалификацией специалистов и требованиями проекта З115 Жизненный цикл информационных систем регламентирует международный стандарт ISO/IEC 12207-2010. Процесс жизни любой системы или программного продукта может быть описан посредством модели жизненного цикла, состоящей из стадий. Модель жизненного цикла представляется в виде последовательности стадий, которые могут перекрываться и (или) повторятся циклически в соответствии с областью применения, размером, сложностью, потребностью в изменениях и возможностями. З116 Первый этап – постановка задачи Второй этап - выбор метода решения Третий этап - разработка алгоритма решения задачи Четвертый этап – кодирование алгоритма Пятый этап – трансляция и компиляция программы Шестой этап – тестирование программы Седьмой этап – создание документации Восьмой этап - сопровождение и эксплуатация З117 Организация и планирование процесса разработки программного продукта предусматривает выполнение следующих работ: определение состава выполняемых работ и группирование их по этапам разработки; предварительная оценка продолжительности выполнения отдельных этапов разработки; установление профессионального состава и количество исполнителей; расчет трудоемкости работ; построение календарного графика выполнения разработок; контроль выполнения календарного графика. Трудоемкость разработки программного продукта зависит от ряда факторов, основными из которых являются следующие: степень новизны разрабатываемого программного комплекса и его функциональное назначение, сложность алгоритма его функционирования, вид представления и структура входной информации. З118 Дельфийский метод — способ организации коллективного интеллекта, разработанный в 1950—1960 годы в США для прогнозирования влияния будущих научных разработок на методы ведения войны (разработан корпорацией RAND, авторами считаются Olaf Helmer, Norman Dalkey, и Nicholas Rescher). Название заимствовано от Дельфийского Оракула. Суть этого метода в том, чтобы с помощью серии последовательных действий — опросов, интервью, мозговых штурмов — добиться максимального консенсуса при определении правильного решения. Анализ с помощью дельфийского метода проводится в несколько этапов, результаты обрабатываются статистическими методами. COnstructive COst MOdel (COCOMO – модель издержек разработки) – это алгоритмическая модель оценки стоимости разработки программного обеспечения, разработанная Барри Боэмом (Barry Boehm). Модель использует простую формулу регрессии с параметрами, определенными из данных, собранных по ряду проектов. Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие. Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. Так, например, практика выполнения ревизии кода, заключающаяся в проверке одним программистом кода, написанного другим программистом, в «экстремальном» варианте представляет собой «парное программирование», когда один программист занимается написанием кода, а его напарник в это же время непрерывно просматривает только что написанный код. З119 Модели (методики, методологии) процессов разработки ПО принято классифицировать по «весу» — количеству формализованных процессов (большинство процессов или только основные) и детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше «вес» модели. Тяжеловесные: RUP, MSF Легковесные или agile-методики. З120 На сегодняшний день в программной инженерии существуют два основных подхода к разработке ПО ЭИС, принципиальное различие между которыми обусловлено разными способами декомпозиции систем. Первый подход называют функционально-модульным или структурным. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй,объектно-ориентированный подход использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. З121 Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование. Является частью общеинженерной дисциплины «инженерия требований» З122 В математике функциональная декомпозиция - это процесс разделения функциональной взаимосвязи на составные части таким образом, чтобы исходная функция могла быть восстановлена (т. Е. Повторно составлена) из этих частей с помощью композиции функций. Функциональное моделирование – это вид моделирования, который подразумевает описание процессов в виде взаимосвязанных, четко структурированных функций. Т.е. главный элемент – это функция (операция), а бизнес-процесс представляется в виде последовательности функций, преобразующих входы процесса в выходы с использованием определенных ресурсов. З123 Структурное проектирование понимается как методология построения алгоритмов, программ и систем, в том числе информационных, в основе которой лежит выявление структуры задачи, определение составляющих компонент и выделение связей между ними. Процесс разделения сложных задач (объектов, систем) на относительно независимые друг от друга подзадачи (части, подсистемы) называется декомпозицией. Как мы видим, выбор архитектуры разрабатываемого ПО определяется задачами, поставленными перед разработчиками, функциональными и эксплуатационными требованиями. З124 Мо́дульное программи́рование — это организация программы как совокупности небольших независимых блоков, называемых модулями, структура и поведение которых подчиняются определённым правилам. Основные концепции модульного программирования каждый модуль имеет единственную точку входа и выхода; размер модуля по возможности должен быть минимизирован; вся система построена из модулей; каждый модуль не зависит от того, как реализованы другие модули. З126 Структурное программирование представляет собой совокупность рекомендуемых технологических приемов, охватывающих выполнение всех этапов разработки ПП и основывается на следующих принципах: нисходящей разработки, рекомендующей на всех этапах вначале определять наиболее общие моменты, а затем поэтапно выполнять детализацию. сквозного структурного контроля, предполагающего проведение содержательного контроля всех этапов разработки. структурного программирования, рекомендующего определенные структуры алгоритмов и стиль программирования. Базовые структуры: следования или последовательности операторов; ветвления или условного оператора; повторения или оператора цикла. З21 |