Разработка программы. Описание и этапы

Содержание:

ВВЕДЕНИЕ

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

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

Цель данного исследования – характеристика алгоритмизации как обязательного этапа разработки программы.

Для достижения цели необходимо выполнить задачи:

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

Объект работы – процесс разработки программы, предмет – алгоритмизация как обязательный этап разработки программы.

1 Разработка программы. Описание и этапы

1.1 Характеристика процесса разработки программы

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

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

Готовыми к выполнению являются только программы, содержащие инструкции в двоичном машинном коде, – программы на языке конкретного компьютера (компьютера с процессором определенной модели или семейства), только такие программы можно загрузить в память компьютера для выполнения. Таким образом, программы в машинном коде не являются «переносимыми», их можно выполнять только на компьютерах с общей архитектурой, системой команд, поддерживаемой этими компьютерами, т.е. одинаковым машинным языком [9].

Разработка программного обеспечения (далее – ПО) – деятельность по созданию нового программного обеспечения. Как и другие традиционные инженерные дисциплины, разработка программного обеспечения имеет дело с проблемами качества, стоимости и надёжности. Некоторые программы содержат миллионы строк исходного кода, которые, как ожидается, должны правильно исполняться в изменяющихся условиях. Сложность ПО сравнима со сложностью наиболее сложных из современных машин, таких как самолёты.

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

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

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

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

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

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

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

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

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

Были определены следующие шаги: разработка системных требований, разработка требований к ПО, анализ, проектирование, кодирование, тестирование, использование (рисунок 1).

Рисунок 1 Водопадная модель разработки ПО

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

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

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

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

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

Спиральная модель была предложена Бэри Боемом в 1988 году для преодоления недостатков водопадной модели, прежде всего, для лучшего управления рисками. Согласно этой модели разработка продукта осуществляется по спирали, каждый виток которой является определенной фазой разработки. В отличие от водопадной модели в спиральной нет предопределенного и обязательного набора витков, каждый виток может стать последним при разработке системы, при его завершении составляются планы следующего витка. Наконец, виток является именно фазой, а не видом деятельности, как в водопадной модели, в его рамках может осуществляться много различных видов деятельности, то есть модель является двумерной [7].

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

Каждый виток имеет следующую структуру (секторы):

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

Схематично спиральная модель разработки программы может быть изображена следующим образом (рисунок 2):

Рисунок 2 Спиральная модель разработки ПО

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

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

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

1.2 Этапы разработки программы

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

1. Постановка задачи – выполняется специалистом в предметной области на естественном языке (русском, английском и т. д.). Необходимо определить цель задачи, ее содержание и общий подход к решению. Возможно, что задача решается точно (аналитически), и без компьютера можно обойтись. Уже на этапе постановки надо учитывать эффективность алгоритма решения задачи на ЭВМ, ограничения, накладываемые аппаратным и программным обеспечением (АО и ПО).
2. Анализ задачи и моделирование – определяются исходные данные и результат, выявляются ограничения на их значения, выполняется формализованное описание задачи и построение (выбор) математической модели, пригодной для решения на компьютере.
3. Разработка или выбор алгоритма решения задачи – выполняется на основе ее математического описания. Многие задачи можно решить различными способами. Программист должен выбрать оптимальное решение. Неточности в постановке, анализе задачи или разработке алгоритма могут привести к скрытой ошибке – программист получит неверный результат, считая его правильным.
4. Проектирование общей структуры программы – формируется модель решения с последующей детализацией и разбивкой на подпрограммы, определяется «архитектура» программы, способ хранения информации (набор переменных, массивов и т. п.).
5. Кодирование – запись алгоритма на языке программирования. Современные системы программирования позволяют ускорить процесс разработки программы, автоматически создавая часть ее текста, однако творческая работа по–прежнему лежит на программисте. Для успешной реализации целей проекта программисту необходимо использовать методы структурного программирования.
6. Отладка и тестирование программы. Под отладкой понимается устранение ошибок в программе. Тестирование позволяет вести их поиск и, в конечном счете, убедиться в том, что полностью отлаженная программа дает правильный результат. Для этого разрабатывается система тестов – специально подобранных контрольных примеров с такими наборами па­раметров, для которых решение задачи известно. Тестирование должно охватывать все возможные ветвления в программе, т. е. проверять все ее инструкции, и включать такие исходные данные, для которых решение невозможно. Проверка особых, исключительных ситуаций,необходима для анализа корректности. Например, программа должна отказать клиенту банка в просьбе выдать сумму, отсутствующую на его счете. В ответст­венных проектах большое внимание уделяется так называемой «защите от дурака» подразумевающей устойчивость программы к неумелому обращению пользователя. Использование специальных программ – отладчиков, которые позволяют выполнять программу по отдельным шагам, просматривая при этом значения переменных, значительно упрощает этот этап [18].
7. Анализ результатов – если программа выполняет моделирование какого–либо известного процесса, следует сопоставить результаты вычислений с результатами наблюдений. В случае существенного расхождения необ­ходимо изменить модель.
8. Публикация результатов работы, передача заказчику для эксплуатации.
9. Сопровождение программы – включает консультации представителей заказчика по работе с программой и обучение персонала. Недостатки и ошибки, замеченные в процессе эксплуатации, должны устраняться [6].

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

2 Алгоритмизация в процессе разработки программы

2.1 Алгоритм. Понятие, характеристики

Алгоритмом называется точное и понятное предписание исполнителю совершить последовательность действий, направленных на решение поставленной задачи. Слово «алгоритм» происходит от имени математика Аль Хорезми, который сформулировал правила выполнения арифметических действий [5]. Первоначально под алгоритмом понимали только правила выполнения четырех арифметических действий над числами. В дальнейшем это понятие стали использовать вообще для обозначения последовательности действий, приводящих к решению любой поставленной задачи. Говоря об алгоритме вычислительного процесса, необходимо понимать, что объектами, к которым применялся алгоритм, являются данные. Алгоритм решения вычислительной задачи представляет собой совокупность правил преобразования исходных данных в результатные [3].

Относящаяся к алгоритму информация и сам алгоритм должны быть представлены на некотором языке. Описание алгоритма зависит от исполнителя – человека или технического средства (ЭВМ). Запись алгоритма для человека может иметь обычный текстуальный вид. Для повышения однозначности словесного описания прибегают к структуризации текста в соответствии с шагами алгоритмического процесса. Когда нужна высокая наглядность, применяют графическую форму записи алгоритмов, например в виде блок–схем. Текстуальная и графическая форма представления предназначена для восприятия человеком в процессе программирования или изучения алгоритма, но эти формы совсем не пригодны для выполнения программ на ЭВМ. ЭВМ воспринимает только определенные конструкции (команды), состав которых задан для каждого типа машины [8]. Алгоритм для ЭВМ следует представить на языке машины.

Непосредственная запись алгоритма на языке машины нерациональна, а естественный язык не подходит для ЭВМ. Поэтому появились языки программирования, которые:

• удовлетворяют требованиям однозначности представления алгоритма;
• более удобны для человека;
• непосредственно «понятны» процессору ЭВМ.

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

• словесно–формульное описание;
• схема алгоритма, составленная с использованием графических блоков (блок–схема);
• алгоритмические языки программирования;
• псевдокод [12].

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

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

Алголо–подобный алгоритмический язык с русским синтаксисом был введён в употребление академиком А. П. Ершовым в середине 1980–х годов, в качестве основы для «безмашинного» курса информатики [16].

Основные служебные слова алгоритмического языка:

Описание алгоритма:

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

Типы данных:

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

Обозначение условий:

• если;
• то;
• иначе;
• все;
• выбор;
• при;
• знач.

Обозначение циклов:

• нц (начало цикла);
• кц (конец цикла);
• пока;
• для;
• от;
• до;
• шаг.

Логические функции и значения для составления выражений:

• и;
• или;
• не;
• да;
• нет;
• Ввод–вывод;
• ввод;
• вывод [16].

Основными свойствами алгоритма являются:

• детерминированность (определенность). Предполагает получение однозначного результата вычислительного процecca при заданных исходных данных. Благодаря этому свойству процесс выполнения алгоритма носит механический характер;
• результативность. Указывает на наличие таких исходных данных, для которых реализуемый по заданному алгоритму вычислительный процесс должен через конечное число шагов остановиться и выдать искомый результат;
• массовость. Это свойство предполагает, что алгоритм должен быть пригоден для решения всех задач данного типа;
• дискретность. Означает расчлененность определяемого алгоритмом вычислительного процесса на отдельные этапы, возможность выполнения которых исполнителем (компьютером) не вызывает сомнений [15].

2.2 Алгоритмизация как этап разработки программы

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

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

ЭВМ непосредственно выполняет программы на машинном языке программирования данной ЭВМ. При этом программа представляет собой набор отдельных команд компьютера. Эти команды являются достаточно «простыми», например, сложение, умножение, сравнение или пересылка отдельных данных. Каждая команда содержит в себе сведения о том, какая операция должна быть выполнена (код операции), с какими операндами (адреса данных или непосредственно сами данные) выполняются вычисления и куда (адрес) должен быть помещен результат [13].

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

• линейные;
• ветвящиеся;
• циклические;

Линейные вычислительные процессы

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

Рисунок 3 Структура линейного алгоритма

Алгоритмы разветвляющейся структуры

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

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

Рисунок 4 Структура разветвляющегося алгоритма

Циклические вычислительные процессы

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

Существуют две схемы циклических вычислительных процессов – с предусловием (рисунок 5) и с постусловием (рисунок 6).

Рисунок 5 Структура циклического алгоритма с предусловием

Рисунок 6 Структура циклического алгоритма с постусловием

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

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

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

Наибольшее распространение благодаря своей наглядности получил графический (блок–схемный) способ записи алгоритмов. Блок–схемой называется графическое изображение логической структуры алгоритма, в котором каждый этап процесса обработки информации представляется в виде геометрических символов (блоков), имеющих определенную конфигурацию в зависимости от характера выполняемых операций. Перечень символов, их наименование, отображаемые ими функции, форма и размеры определяются ГОСТами. Основные блоки для составления алгоритмов в процессе разработки программы представлены в таблице 1 [8].

Таблица 1

Основные блоки для составления алгоритмов

Название	Обозначение	Описание
Терминатор		Начало, конец, прерывание процесса обработки данных или выполнения программы
Процесс		Выполнение операции или группы операций, в результате которых изменяется значение, форма представления или расположение данных
Предопределенный процесс		Использование ранее созданных и отдельно описанных алгоритмов или программ
Ввод–вывод		Преобразование данных в форму, пригодную для обработки (ввод) или отображения результатов обработки (вывод)
Решение		Выбор направления выполнения алгоритма или программы в зависимости от некоторых переменных условий Блок решения имеет 1 вход и по крайней мере 2 выхода
Границы цикла	Начало цикла Конец цикла	Символ, состоящий из двух частей, отображает начало и конец цикла. Обе части символа имеют один идентификатор. Условия для инициализации, приращения, завершения и т. д. помещаются внутри символа в начале или в конце в зависимости от расположения операции, проверяющей условие.
Подготовка		Выполнение операций, меняющих команды или группу команд, с целью воздействия на некоторую последующую функцию (установка переключателя, модификация регистра, инициализация программы)
Комментарий		Пояснение к элементу схемы (или линии связи)
Соединитель		При большой насыщенности схемы отдельные линии потока между удаленными символами допускается обрывать. При этом в конце (начале) обрыва должен быть помещен символ «Соединитель». Внутри блока соединителя указывается имя уникального идентификатора.

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Агафонов, В. Н. Логическое программирование / В. Н. Агафонов. – М.: Форум, 2016. – 718 c.
2. Бек, Л. Введение в системное программирование / Л. Бек. – М.: Мир, 2016. – 448 c.
3. Голицына, О. Л. Основы алгоритмизации и программирования / О. Л. Голицына, И.И. Попов. – М.: Форум, 2015. – 432 c.
4. Дегтерева, Р. Необычные эффекты алгоритмизации / Р. Дегтерева. – М.: LAP Lambert Academic Publishing, 2017. – 140 c.
5. Долгов, А. И. Алгоритмизация прикладных задач. Учебное пособие / А. И. Долгов. – М.: Флинта, 2016. – 175 c.
6. Канцедал, С. А. Алгоритмизация и программирование / С. А. Канцедал. – М.: Форум, Инфра–М, 2014. – 352 c
7. Кнут, Д. Э. Искусство программирования (Том 1. Основные алгоритмы) / Д. Э. Кнут. – М.: Мир, 2017. – 882 c.
8. Колдаев, В. Д. Основы алгоритмизации и программирования / В. Д. Колдаев. – М.: Форум, Инфра–М, 2018. – 416 c.
9. Комлев, Н. Ю. Объектно Ориентированное Программирование. Хорошая книга для Хороших Людей / Н. Ю. Комлев. – М.: Солон–Пресс, 2014. – 892 c.
10. Корниенко, М. М. Информатика. Основы алгоритмизации и программирования. Теоретические основы, примеры и задания, практические работы / М.М. Корниенко. – М.: Ранок, 2018. – 259 c.
11. Кьоу Дж. Объектно–ориентированное программирование / Дж. Кьоу, М. Джеанини. – М.: Питер, 2015. – 240 c.
12. Потопахин, В. В. Искусство алгоритмизации. Учебное пособие / В. В. Потопахин. – М.: ДМК Пресс, 2018. – 328 c.
13. Санников, Е. В. Курс практического программирования в Delphi. Объектно–ориентированное программирование / Е. В. Санников. – М.: Солон–Пресс, 2017. – 188 c.
14. Судзиловский, В. Ю. Моделирование и алгоритмизация в САПР / В. Ю. Судзиловский. – М.: Книжный клуб 36.6, 2017. – 270 c.
15. Трофимов, В. В. Алгоритмизация и программирование. Учебник для академического бакалавриата / В. В. Трофимов. – М.: Юрайт, 2017. – 315 c
16. Фалина, И. Н. Алгоритмизация и программирование (+ CD–ROM) / И. Н. Фалина и др. – М.: КУДИЦ–Пресс, 2019. – 280 c.
17. Хорев, П. Б. Объектно–ориентированное программирование / П. Б. Хорев. – М.: Academia, 2017. – 448 c.
18. Хювёнен, Э. Мир Лиспа. Том 2. Методы и системы программирования / Э. Хювёнен, И. Септянен. – М.: КУДИЦ, 2015. – 742 c.