Файл: Алгоритмизация как обязательный этап разработки программы (Характеристика процесса разработки программы).pdf

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

---

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

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

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

Основные элементы программирования:

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

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

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

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

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

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

---

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

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

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

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

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

---

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

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

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

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

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

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

---

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

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

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

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

---