Файл: Основы проектирования программ. Этапы создания программного обеспечения (Основы проектирования программ).pdf
Добавлен: 31.03.2023
Просмотров: 89
Скачиваний: 2
Введение
Разработка программного обеспечения представляет собой процесс, включающий в себя несколько аспектов. Этот процесс творческий, ведь он требует полной отдачи от разработчиков. Вот только разработка ПО часто не обходится без проблем с уровнем качества, размером финансовых вложений и низкой надёжностью.
Процесс разработки программного обеспечения проходит в несколько этапов. Данные этапы описывают уровень готовности создаваемого программного продукта. Для любого ПО крайне важно качество разработки, ведь испытания и весь процесс создания иногда может длиться несколько месяцев, необходимо делать огромное количество измерений, а это в свою очередь серьезные затраты времени и денег. Немаловажную роль во всем этом процессе должно играть высокое качество и удобство разработанного интерфейса, а также полная удовлетворенность заказчика. Для любой профессиональной компании эти составляющие должны стоять на первом месте.
Тема исследования: Основы проектирования программ. Этапы создания программного обеспечения.
Цель исследования: Изучить основы проектирования программ и этапы создания программного обеспечения.
Объект исследования: Проектирование программ.
Предмет исследования: Основы проектирования программ.
Задачи исследования: изучить:
Модели жизненного цикла ПО
Этапы жизненного цикла ПО
Основы проектирования программ
Этапы создания программного обеспечения.
1.Основы проектирования программ.
Основная задача любого успешного проекта заключается в том, чтобы на момент запуска системы и в течение всего срока ее эксплуатации можно было обеспечить:
• требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;
• требуемую пропускную способность системы;
• требуемое время реакции системы на запрос;
• безотказную работу системы в требуемом режиме, то есть: готовность и доступность системы для обработки запросов пользователей;
• простоту эксплуатации и поддержки системы;
• требуемую безопасность.
Производительность является главным фактором, который определяет эффективность системы. Хорошее проектное решение — основа высокопроизводительной системы.
Проектирование информационных систем охватывает три основные области:
• проектирование объектов данных, которые будут реализованы в базе данных;
• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• учет конкретной среды или технологии: топологии сети, конфигурации аппаратных средств, использования архитектур «файл-сервер», «клиент-сервер», параллельной обработки, распределенной обработки данных и т.п.
В реальных условиях проектирование информационных систем — это поиск способа, который обеспечивает необходимую функциональность системы средствами имеющихся технологий с учетом заданных ограничений.
Под методологией разработки подразумевается набор методов и критериев оценки, которые используются для постановки задачи, планирования, контроля и в конечном итоге — для достижения поставленной цели. Сам процесс разработки описывается моделью, которая определяет последовательность наиболее общих этапов и получаемых результатов.
Долгое время процесс разработки ПО осуществлялся в соответствии с методиками, наработанными в инженерной области, — стандартная практика поэтапного создания продукта, начиная с составления спецификаций и заканчивая поставкой заказчику. Существуют стандарты ГОСТ (Россия) и ISO (Европа, Россия), CMM (Capability Maturity Model — распространен в США), регламентирующие данный процесс.
1.2. Общие принципы разработки программ
Программы различаются по назначению, выполняемым функциям, формам реализации. Однако можно полагать, что существуют некоторые общие принципы, которые следует использовать при разработке программ.
Частотный принцип. Принцип основан на выделении в алгоритмах и данных особых групп по частоте использования. Для действий, наиболее часто встречающихся при работе программ, создаются условия их быстрого выполнения. К часто используемым данным обеспечивается наиболее быстрый доступ. «Частые» операции стараются делать более короткими. Следует отметить, что лишь не более 5 % операторов программы оказывают ощутимое влияние на скорость выполнения программы. Этот факт позволяет значительную часть операторов программы кодировать без учета скорости вычислений, обращая основное внимание при этом на «красоту» и наглядность текстов.
Принцип модульности. Под модулем в данном контексте понимают функциональный элемент рассматриваемой системы, имеющий оформление, законченное и выполненное в пределах требований системы, и средства сопряжения с подобными элементами или элементами более высокого уровня данной или другой системы. Способы обособления составных частей программ в отдельные модули могут различаться существенно. В значительной степени разделение системы на модули определяется используемым методом проектирования программ.
Принцип функциональной избирательности. Этот принцип является логическим продолжением частотного и модульного принципов и используется при проектировании программ. В программах выделяется некоторая часть важных модулей, которые постоянно должны быть в состоянии готовности для эффективной организации вычислительного процесса. Эту часть в программах называют ядром или монитором. При формировании состава монитора требуется учесть два противоречивых требования. В состав монитора, помимо чисто управляющих модулей, должны войти наиболее часто используемые модули. Количество модулей должно быть таким, чтобы объем памяти, занимаемой монитором, был не слишком большим. Программы, входящие в состав монитора, постоянно хранятся в оперативной памяти. Остальные части программ постоянно хранятся во внешних запоминающих устройствах и загружаются в оперативную память только при необходимости, перекрывая друг друга также при необходимости.
Принцип генерируемости. Основное положение этого принципа определяет такой способ исходного представления программы, который бы позволял осуществлять настройку на конкретную конфигурацию технических средств, круг решаемых проблем, условия работы пользователя.
Принцип функциональной избыточности. Этот принцип учитывает возможность проведения одной и той же работы различными средствами. Особенно важен учет этого принципа при разработке пользовательского интерфейса для выдачи одних и тех же данных разными способами вызова из-за психологических различий в восприятии информации [5].
Принцип «по умолчанию». Применяется для облегчения организации связей с системой как на стадии генерации, так и при работе с уже готовыми программами. Принцип основан на хранении в системе некоторых базовых описаний структур, модулей, конфигураций оборудования и данных, определяющих условия работы с программой. Эту информацию программа использует в качестве заданной по умолчанию, если пользователь забудет или сознательно не конкретизирует ее.
1.3 Жизненный цикл программного обеспечения
Известны несколько основных моделей жизненного цикла ПО.
Жизненный цикл программного обеспечения (ПО) – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.
Для облегчения проектирования, создания и выпуска качественного программного продукта существуют различные модели жизненного цикла ПО.
Требования к проекту являются определяющими при выборе подхода к циклу разработки. В данной статье мы рассмотрим основные методологии в разработке ПО [7].
Каскадная или водопадная модель (Waterfall model)
При такой модели каждая из фаз проекта проводится единожды, следуя одна за другой. Для того, чтобы начать следующую стадию, необходимо полное завершение предыдущей.
Плюсы:
все стадии проекта выполняются в строгой последовательности;
строгость этапов позволяет планировать сроки завершения всех работ и соответствующие ресурсы (денежные и человеческие);
требования остаются неизменными в течение всего цикла.
Минусы:
сложности при формулировке четких требований и невозможность их изменения;
тестирование начинается только с середины развития проекта;
до завершения процесса разработки пользователи не могут убедиться, качествен ли разрабатываемый продукт.
Рисунок 1.1 Каскадная модель
V-образная модель (V-model)
Данная модель стала последователем каскадной модели, так как с ее помощью можно устранить недостатки, которые были ранее [3].
Суть этой модели состоит в том, что процессы на всех этапах контролируются, чтобы убедиться в возможности перехода на следующий уровень. Уже на стадии написания требований начинается процесс тестирования.
Плюсы:
строгая этапизация;
минимизация рисков и устранение потенциальных проблем за счет того, что тестирование появляется на самых ранних стадиях;
усовершенствованный тайм-менеджмент.
Минусы:
невозможность адаптироваться к измененным требованиям заказчика;
длительное время разработки (иногда длится до нескольких лет) приводит к тому, что продукт может быть уже не нужен заказчику, поскольку его потребности меняются;
нет действий, направленных на анализ рисков.
Рисунок 1.2 V-образная модель
Инкрементная модель (Incremental model)
При инкрементной модели (англ. increment – увеличение, приращение) программное обеспечение разрабатывается с линейной последовательностью стадий, но в несколько инкрементов (версий). Таким образом улучшение продукта проходит запланировано все время пока жизненный цикл разработки ПО не завершится.
Требования к системе определяются в самом начале работы, после чего процесс разработки проводится в виде последовательности версий, каждая из которых является законченным и работоспособным продуктом.
Плюсы:
заказчик может дать свой отзыв касательно каждой версии продукта;
есть возможность пересмотреть риски, которые связаны с затратами и соблюдением графика;
привыкание заказчика к новой технологии происходит постепенно.
Минусы:
функциональная система должна быть полностью определена в начале жизненного цикла для выделения итераций;
при постоянных изменениях структура системы может быть нарушена;
сроки сдачи системы могут быть затянуты из-за ограниченности ресурсов (исполнители, финансы).
Рисунок 1.3 Инкрементная модель модель
Спиральная модель (Spiral model)
В спиральной модели жизненный путь разрабатываемого продукта изображается в виде спирали, которая, начавшись на этапе планирования, раскручивается с прохождением каждого следующего шага. Таким образом, на выходе из очередного витка получаем готовый протестированный прототип, который дополняет существующую сборку. Прототип, удовлетворяющий всем требованиям, готов к выпуску [1].
Плюсы:
управлению рисками уделяется особое внимание;
дополнительные функции могут быть добавлены на поздних этапах;
есть возможность гибкого проектирования.
Минусы:
оценка рисков на каждом этапе является довольно затратной;
постоянные отзывы и реакция заказчика может провоцировать все новые и новые итерации, которые могут приводить к временному затягиванию разработки продукта;
более применима для больших проектов.
Рисунок 1.4 Спиральная модель
Гибкая модель (Agile model)
Представляет собой совокупность различных подходов к разработке ПО. Включает серии подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки (в Scrum итерации называются спринтами), динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Отдельная итерация представляет собой миниатюрный программный проект. Одной из основных идей Agile является взаимодействие внутри команды и с заказчиком лицом к лицу.
Плюсы:
быстрое принятие решений за счет постоянных коммуникаций;
минимизация рисков;
облегченная работа с документацией.
Минусы:
большое количество митингов и бесед, что может увеличить время разработки продукта;