Добавлен: 23.04.2023
Просмотров: 67
Скачиваний: 4
ВВЕДЕНИЕ
Создание программного обеспечения является сегодня одной из передовых отраслей мировой экономики. Данный факт абсолютно закономерен, если учитывать высокие темпы развития информационных технологий и средств обработки данных, которые будут только совершенствоваться и усложняться. Разработка программы – сложны, многогранный и многоэтапный процесс, который требует от участников высокой квалифицированности, опыта и некоторой дисциплинированности. В частности, для того, чтобы не просто сделать отличный программный продукт, но сделать это еще и с минимальными ресурсными издержками, требуется внимательное и кропотливое выполнение всех этапов разработки, определенных для конкретного проекта.
Одним из обязательных этапов разработки для любого продукта является алгоритмизация. Алгоритм представляет собой последовательность действий, которые ведут к желаемому результату. Алгоритмизация в процессе разработки программного обеспечения позволяет не только структурировать работу будущей программы, но также и наглядно показать возможные ошибки и недочеты.
Цель данного исследования – характеристика алгоритмизации как обязательного этапа разработки программы.
Для достижения цели необходимо выполнить задачи:
- охарактеризовать процесс разработки программы в целом;
- проанализировать этапы разработки программного обеспечения;
- рассмотреть понятие и основные характеристики алгоритма;
- рассмотреть алгоритмизацию со стороны обязательного этапа разработки программы.
Объект работы – процесс разработки программы, предмет – алгоритмизация как обязательный этап разработки программы.
1 Разработка программы. Описание и этапы
1.1 Характеристика процесса разработки программы
Программа – это последовательность инструкций (команд), описывающая алгоритм решения с помощью компьютера соответствующей задачи, для реализации которой эта программа была разработана [7].
Для разработки программ используются специальные языки. Программа может содержать инструкции, написанные на языках программирования высокого уровня, которые позволяют записать алгоритмы в удобной для понимания человеком форме, приближенной к естественным языкам (исходный код), или последовательность машинных команд (инструкций, «понятных» компьютеру, на котором данная программа должна выполняться).
Готовыми к выполнению являются только программы, содержащие инструкции в двоичном машинном коде, – программы на языке конкретного компьютера (компьютера с процессором определенной модели или семейства), только такие программы можно загрузить в память компьютера для выполнения. Таким образом, программы в машинном коде не являются «переносимыми», их можно выполнять только на компьютерах с общей архитектурой, системой команд, поддерживаемой этими компьютерами, т.е. одинаковым машинным языком [9].
Разработка программного обеспечения (далее – ПО) – деятельность по созданию нового программного обеспечения. Как и другие традиционные инженерные дисциплины, разработка программного обеспечения имеет дело с проблемами качества, стоимости и надёжности. Некоторые программы содержат миллионы строк исходного кода, которые, как ожидается, должны правильно исполняться в изменяющихся условиях. Сложность ПО сравнима со сложностью наиболее сложных из современных машин, таких как самолёты.
Процесс создания ПО – множество различных видов деятельности, методов, методик и шагов, используемых для разработки и эволюции ПО и связанных с ним продуктов (проектных планов, документации, программного кода, тестов, пользовательской документации и пр.) [11].
На сегодняшний день не существует универсального процесса разработки ПО – набора методик, правил и предписаний, подходящих для обеспечения любого вида, для любых компаний, для команд любой национальности. Каждый текущий процесс разработки, осуществляемый некоторой командой в рамках определенного проекта, имеет большое количество особенностей и индивидуальностей. Однако целесообразно перед началом проекта спланировать процесс работы, определив роли и обязанности в команде, рабочие продукты (промежуточные и финальные), порядок участия в их разработке членов команды и т.д. [1]
Процесс создания программ не является однородным. Тот или иной метод разработки ПО, как правило, определяет некоторую динамику развертывания тех или иных видов деятельности, то есть, определяет модель процесса.
Модель является хорошей абстракцией различных методов разработки ПО, позволяя лаконично, сжато и информативно их представить. Однако сама идея модели процесса является одной из самых ранних в программной инженерии, когда считалось, что удачная модель – самое главное, что способствует успеху разработки. Позднее пришло осознание, что существует множество других аспектов (принципы управления и разработки, структура команды и т.д.), которые должны быть определены согласованно друг с другом. И стали развиваться интегральные методологии разработки. Тем не менее, существует несколько классических моделей процесса, которые полезны на практике и которые будут рассмотрены ниже.
Говоря о моделях процессов, необходимо различать фазы и виды деятельности. Фаза – это определенный этап процесса, имеющий начало, конец и выходной результат. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы [2].
Редко какой заказчик согласится первый раз увидеть результаты только после завершения проекта. С другой стороны, подрядчики предпочитают получать деньги постепенно, по мере того, как выполняются отдельные части работы. Таким образом, появляются фазы, позволяющие создавать и предъявлять промежуточные результаты проекта. Фазы полезны также безотносительно взаимодействия с заказчиком – с их помощью можно синхронизировать деятельность разных рабочих групп, а также отслеживать продвижение проекта. Примерами фаз может служить согласование с заказчиком технического задания, реализация определенной функциональности ПО, этап разработки, оканчивающийся сдачей системы на тестирование или выпуском альфа–версии.
Вид деятельности – это определенный тип работы, выполняемый в процессе разработки ПО. Разные виды деятельности часто требуют разные профессиональные навыки и выполняются разными специалистами. Например, управление проектом выполняется менеджером проекта, кодирование – программистом, тестирование – тестировщиком. Есть виды деятельности, которые могут выполняться одними и теми же специалистами – например, кодирование и проектирование (особенно в небольшом проекте) часто выполняют одни и те же люди.
В рамках одной фазы может выполняться много различных видов деятельности. Кроме того, один вид деятельности может выполняться на разных фазах – например, тестирование: на фазе анализа и проектирования можно писать тесты и налаживать тестовое окружение, при разработке и перед сдачей производить, собственно, само тестирование. На настоящий момент для сложного программного обеспечения используются многомерные модели процесса, в которых отделение фаз от видов деятельности существенно облегчает управление разработкой ПО [2]. Фазы и виды деятельности разными способами соединяются в различных моделях разработки программного обеспечения.
Водопадная модель была предложена в 1970 году Винстоном Ройсом. Фактически, впервые в процессе разработки ПО были выделены различные шаги разработки и поколеблены примитивные представления о разработке ПО в виде анализа системы и ее кодирования [3].
Были определены следующие шаги: разработка системных требований, разработка требований к ПО, анализ, проектирование, кодирование, тестирование, использование (рисунок 1).
Рисунок 1 Водопадная модель разработки ПО
Достоинством этой модели явилось ограничение возможности возвратов на произвольный шаг назад, например, от тестирования – к анализу, от разработки – к работе над требованиями и т.д. Отмечалось, что такие возвраты могут катастрофически увеличить стоимость проекта и сроки его выполнения. Например, если при тестировании обнаруживаются ошибки проектирования или анализа, то их исправление часто приводит к полной переделке системы. Этой моделью допускались возвраты только на предыдущий шаг, например, от тестирования к кодированию, от кодирования к проектированию и т.д.
Наконец, в рамках этой модели было введено прототипирование, то есть предлагалось разрабатывать систему дважды, чтобы уменьшить риски разработки. Первая версия – прототип – позволяет увидеть основные риски, и обосновано принять главные архитектурные решения. На создание прототипа отводилось до одной трети времени всей разработки [3].
В 70–80 годах прошлого века эта модель прочно укоренилась в разработке ПО в силу своей простоты и сходности с моделями разработки иных, не программных систем. В дальнейшем, в связи с развитием программной инженерии и осознанием итеративного характера процесса разработки ПО эта модель активно критиковалась, практически каждым автором соответствующих статей и учебников. Стало общепринятым мнение, что она не отражает особенностей разработки ПО [3]. Недостатками водопадной модели являются:
- отождествление фаз и видов деятельности, что влечет потерю гибкости разработки, в частности, трудности поддержки итеративного процесса разработки;
- требование полного окончания фазы–деятельности, закрепление результатов в виде подробного исходного документа (технического задания, проектной спецификации); однако опыт разработки ПО показывает, что невозможно полностью завершить разработку требований, дизайн системы и т.д. – все это подвержено изменениям; и причины тут не только в том, что подвижно окружение проекта, но и в том, что заранее не удается точно определить и сформулировать многие решения, они проясняются и уточняются лишь впоследствии;
- интеграция всех результатов разработки происходит в конце, вследствие чего интеграционные проблемы дают о себе знать слишком поздно;
- пользователи и заказчик не могут ознакомиться с вариантами системы во время разработки, и видят результат только в самом конце; тем самым, они не могут повлиять на процесс создания системы, и поэтому увеличиваются риски непонимания между разработчиками и пользователями/заказчиком;
- модель неустойчива к сбоям в финансировании проекта или перераспределению денежных средств, начатая разработка, фактически, не имеет альтернатив «по ходу дела».
Однако данная модель продолжает использоваться на практике – для небольших проектов или при разработке типовых систем, где итеративность не так востребована. С ее помощью удобно отслеживать разработку и осуществлять поэтапный контроль над проектом. Эта модель также часто используется в оффшорных проектах с почасовой оплатой труда.
Спиральная модель была предложена Бэри Боемом в 1988 году для преодоления недостатков водопадной модели, прежде всего, для лучшего управления рисками. Согласно этой модели разработка продукта осуществляется по спирали, каждый виток которой является определенной фазой разработки. В отличие от водопадной модели в спиральной нет предопределенного и обязательного набора витков, каждый виток может стать последним при разработке системы, при его завершении составляются планы следующего витка. Наконец, виток является именно фазой, а не видом деятельности, как в водопадной модели, в его рамках может осуществляться много различных видов деятельности, то есть модель является двумерной [7].
Последовательность витков может быть такой: на первом витке принимается решение о целесообразности создания ПО, на следующем определяются системные требования, потом осуществляется проектирование системы и т.д. Витки могут иметь и иные значения.
Каждый виток имеет следующую структуру (секторы):
- определение целей, ограничений и альтернатив проекта;
- оценка альтернатив, оценка и разрешение рисков; возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций; фокусировка на самых рисковых частях проекта;
- разработка и тестирование – здесь возможна водопадная модель или использование иных моделей и методов разработки ПО;
- планирование следующих итераций – анализируются результаты, планы и ресурсы на последующую разработку, принимается (или не принимается) решение о новом витке; анализируется, имеет ли смысл продолжать разрабатывать систему или нет; разработку можно и приостановить, например, из–за сбоев в финансировании; спиральная модель позволяет сделать это корректно [7].
Схематично спиральная модель разработки программы может быть изображена следующим образом (рисунок 2):
Рисунок 2 Спиральная модель разработки ПО
Отдельная спираль может соответствовать разработке некоторой программной компоненты или внесению очередных изменений в продукт. Таким образом, у модели может появиться третье измерение.