каскадная, поэтапная модель с промежуточным контролем, спиральная, инкрементная»

Содержание:

ВВЕДЕНИЕ

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

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

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

Целью курсовой работы является расширение и закрепление теоретических знаний по дисциплине «Оптимизация программных систем».

Для достижения поставленной задачи в первой главе курсовой работы

описаны понятие и архитектура ПС, методы структурного программирования, на примере микроядерной операционной системы рассмотрен «клиент-серверный» подход модульной организации ПС, как основной принцип взаимодействия между модулями.

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

При написании работы использовались научные труды следующих авторов: С. В. Назарова, С. А. Орлова, П. С. Макарова и других авторов.

1. ПОНЯТИЕ ПРОГРАММНОЙ СИСТЕМЫ. АРХИТЕКТУРА И МЕТОДОЛОГИЯ ПРЕКТИРОВАНИЯ ПРОГРАММНОЙ СИСТЕМЫ

1.1. Понятие программной системы

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

Программное обеспечение (Software) – совокупность программ (комбинация компьютерных инструкций и данных), выполняемых вычислительной системой.

Аппаратное обеспечение (hardware) – это совокупность технических средств (электронных и механических устройств), обеспечивающих, как нормальное функционирование каких-либо электронных систем – компьютеров, сетей передачи данных, так и расширяющих их основные функции.

Данные – поддающееся многократной интерпретации представление информации в формализованном виде, пригодном для передачи, связи, или обработки [10].

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

В своей монографии «Архитектуры и проектирование программных систем» С. В. Назаров приводит ряд критериев, отличающих программные системы от небольших программ [4]. Вот некоторые из них:

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

Стоит обратить внимание, что одного какого-либо критерия недостаточно, чтобы программу считать программной системой. Сам термин «программная система» «намекает» на наличие некоторого числа (не менее двух) критериев.

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

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

В работе С. В. Назарова и др. «Введение в программные системы и их разработку»[5] приводится процесс создания программ, как последовательность: постановка задачи (problem definition) – алгоритм (algorithm) – программирование (programming).

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

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

Программирование – теоретическая и практическая деятельность, связанная с созданием программ.

Программные системы могут входить в состав программных комплексов. Обычно это более масштабные системы в рамках больших технических и организационных систем, например аппаратно-программный комплекс «TouchInform».

1.2. Архитектура программной системы

В методологии проектирования ПС понятие архитектура занимает ключевое место.

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

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

Компонентом называют модульную часть системы, которая инкапсулирует ее содержимое.

1.3. Структурное программирование

Идеи структурного программирования появились в начале 70-годов в компании IBM, в их разработке участвовали известные ученые Э. Дейкстра, Х. Милс, Э. Кнут, С. Хоор.

Структурное проектирование подразумевает использование структур для разделения различных частей системы. Каждая часть при этом может проектироваться отдельно (рис. 1).

Рисунок 1 – Этап структурного программирования

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

Один из наиболее традиционных методов проектирования операционных систем в 70-е гг. XX в. состоял в том, что проект каждого основного модуля системы выполнялся отдельно. Этот подход называется модульно-интерфейсным.

1.4. Методы структурного проектирования

Методология программирования (проектирования программных систем) – это комплекс методов, применяемых на различных стадиях жизненного цикла программного обеспечения и имеющих общий философский подход [6].

Методы проектирования – это обычно зависящие от области приложения (предметной области) тактические средства, определяющие те или иные этапы процесса проектирования. Сам процесс проектирования подразумевает принятие решения о форме и содержании предмета проектирования.

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

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

Существуют различные методы разработки модульной структуры программной системы, в зависимости от которых определяется порядок разработки структуры системы, программирования и отладки модулей, указанных в этой структуре. Наиболее распространены две методики (стратегии) разработки программ при разработке программных систем: аналитический метод, или метод «сверху вниз», и синтетический метод, или метод «снизу вверх».

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

1.5. Технология модульного программирования

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

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

1.5.1. Нисходящее программирование

В основу метода «сверху вниз» (bottom-up) заложена идея пошаговой детализации. Программа конструируется иерархически – сверху вниз: от главной программы к подпрограммам самого нижнего уровня (рис. 2). Модуль верхнего уровня соответствует общей функции программы, а модули следующего уровня представляют ее подфункции.

Рисунок 2 – Последовательность проектирования «сверху вниз»

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

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

Заглушка – это простой по структуре программный модуль, в котором входные и выходные данные соответствуют замещаемому модулю, но алгоритм обработки данных значительно упрощен. Часто в программе–заглушке помимо описания входных и выходных данных присутствует один оператор печати, сообщающий о том, что в этом месте программы вызывается заглушка [8].

Нисходящий способ проектирования упрощает интегрирование модулей в единую программу.

1.5.2. Восходящее программирование

Проектирование «снизу вверх» (top-down) – способ разработки программ, при которой крупные блоки (модули) собираются из ранее созданных мелких блоков (рис. 3).

Рисунок 3 – Последовательность проектирования «снизу вверх»

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

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

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

1.6. Клиент-серверный подход

Разработка программной системы в архитектурном стиле «клиент - сервер» является популярным решением для систем, состоящих из клиента – программы, использующей ресурсы, и сервера – программы, обслуживающей запросы клиента и обеспечивающей их выполнение. Функциональность всей системы обеспечивается комплексов сервисов, каждый из которых располагается на своем сервере [7].

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

Подход «клиент-сервер», как основной принцип взаимодействия между модулями реализован в микроядерной архитектуре ОС, где в привилегированном режиме работает небольшая часть ОС, называемая микроядром [3]. Ядро составляют машинно-зависимые модули и модули, выполняющие базовые механизмы, например, управление физической и виртуальной памятью компьютера, управление процессорным временем. Другие, более высокоуровневые функции ядра, оформлены как обособленные модули, работающие в пользовательском режиме (рис. 4). К ним относятся драйверы устройств, файловые системы и др.

Рисунок 4 – Микроядерная архитектура ОС

Модули, работающие в пользовательском режиме (менеджеры ресурсов) взаимодействуют между собой путем обмена сообщениями, которые передаются через микроядро. Их основная задача – реализация обслуживающих процессов – запросов клиента, которым может быть как локальное приложение, так и другой модуль ОС [2]. Каждый сервер, работающий в пользовательском режиме, выполняет отдельный набор сервисных функций, например, управление памятью, создание или планирование процессов. Ядро получает от клиента запрос сервиса и передает сообщение конкретному серверу, находящемуся в состоянии ожидания. Сервер выполняет операцию и через ядро ответным сообщением возвращает результаты клиенту (рис. 5). Один и тот же программный компонент может выступать как в роли клиента, запрашивая какой-либо сервис у другого компонента, так и сам может выступать в роли сервера, по запросу выполняя нужные операции, например, сервер процессов может как выполнять запросы, поступающие от приложений пользователя, так и сам обращаться к серверу безопасности.

Рисунок 5 – Реализация системного вызова в микроядерной архитектуре

Использование модели «клиент-сервер» повышает надежность. В микроядерной операционной системе микроядру отведена роль реализации только жизненно важных функций, лежащих в основе ОС. Другие компоненты ОС, например, управление окнами и обеспечение безопасности, теперь оформлены, как периферийные модули. Каждый сервер выполняется в виде отдельного процесса в своей собственной области памяти в пространстве пользователя, благодаря этому, они защищены от других процессов и не имеют непосредственного доступа к аппаратуре, а значит не могут модифицировать память, в которой хранится управляющая программа. В случае, если отдельный сервер потерпел крах, он может быть перезапущен без остановки или повреждения остальной части ОС [2].

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

2. ЖИЗНЕННЫЕ ЦИКЛЫ ПРОГРАММНЫХ СИСТЕМ

2.1. Понятие жизненного цикла. Процессы жизненного цикла

У любой программной системы есть жизненный цикл (life cycle) – стадии, через которые она проходит с момента принятия решения о необходимости создании ПС до ее изъятия из эксплуатации.

Методология проектирования программных систем – это комплекс регламентов и стандартов, применяемые на различных стадиях жизненного цикла программного обеспечения. Методология проектирования рассматривает жизненный цикл (ЖЦ), как процесс создания и сопровождения программных систем с описанием его стадий, а также действий и задач, которые должны быть выполнены на каждой стадии. Каждому этапу жизненного цикла программной системы (ЖЦ ПС) присущи свой состав и последовательность выполняемых работ, методы и средства выполнения, роли и ответственность участников, получаемые результаты и т.д.

Состав процессов ЖЦ ПС регламентирует международный стандарт ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes» [11]. В соответствии со стандартом все процессы ЖЦ разделены на три группы [4]:

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

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

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

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

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

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

а) изменению программного продукта и услуг,

б) изменению цены на них,

в) проведению модификации или снятию с продажи и предоставления.

2.2. Модели и стадии ЖЦ ПС

Под моделью жизненного цикла (life cycle model) программной системы понимается последовательность и взаимосвязь процессов и выполняемых специалистами действий и задач на всем протяжении ЖЦ ПС. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.

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

Основное назначение моделей ЖЦ:

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

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

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

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

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

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

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

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

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

2.3. Каскадная модель

Классическим жизненным циклом считается каскадная модель (Waterfall model, «водопад»), предложенная Уинстоном Ройсом в 1970 г. Особенностью модели, отраженной в названии, является поэтапная разработка с переходом на нижнюю ступень только после завершения всех работ на предыдущей ступени.

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

Рисунок 6 – Каскадная модель ЖЦ ПС

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

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

Преимущества каскадной модели:

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

Недостатки каскадной модели:

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

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

2.3.1. Макетирование

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

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

Этапы макетирования отражены на рисунке 7 – Последовательность действий при макетировании.

Рисунок 7 – Последовательность действий при макетировании

2.4. Каскадная модель с промежуточным контролем

Каскадная модель с промежуточным контролем («водоворот», или итерационная модель) является модификацией предыдущей модели. Промежуточный контроль осуществляется с помощью циклов обратной связи между этапами. Этапы, как и в модели «водопад» расположены последовательно, но каждый следующий этап имеет связь с предыдущими (рис.8).

Рис 8 – Каскадная модель с промежуточным контролем

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

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

2.5. Инкрементная модель

Инкрементная модель (Incremental model, «increment» в переводе с англ. — приращение) представляет собой процесс частичной реализации всей системы с итерационным наращиванием функционала, т.е. постепенным добавлением нового. У данной модели ЖЦ есть и другое определение. Когда говорят о структуре жизненного цикла, то модель называют итеративной (iterative). Инкрементальной же модель ЖЦ называют, имея в виду процесс наращивания функциональности продукта.

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

Первый инкремент реализует базовую версию продукта, включающую основные требования. Следующий инкремент включает в себя некоторую модификацию базового продукта, содержащую дополнительные характеристики и функциональность (рис. 9). Каждый инкремент проектируется независимо от другого, и по мере готовности может быть передан заказчику и внедрен в эксплуатацию. Благодаря этому реализуется одно из преимуществ разработки проекта на основе инкрементной модели жизненного цикла.

Рисунок 9 – Инкрементная модель ЖЦ ПС

Преимущества инкрементной модели:

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

Недостатки инкрементной модели:

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

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

2.6. Спиральная модель

Спиральная модель (Spiral model) – классический пример применения эволюционной стратегии конструирования. Модель, предложенную Барри Боэмом, начали использовать с 1988 года. В спиральной модели сохранены лучшие свойства классического жизненного цикла и добавлен новый элемент – анализ рисков, которому уделяется большое внимание.

Боэм сформулировал десять наиболее распространённых рисков, среди них: дефицит специалистов, нереалистичные сроки и бюджет, разработка неправильного пользовательского интерфейса, недостаточная производительность получаемой системы и др. [12].

Спиральная модель представлена в виде четырех процессов, каждый из которых является отдельным этапом разработки:

• планирование – определение целей;
• анализ рисков;
• разработка и тестирование;
• планирование следующей итерации.

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

Рисунок 10 – Спиральная модель ЖЦ ПС

Преимущества спиральной модели:

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

Недостатки спиральной модели:

• значительная длительность разработки, а вместе с тем и дороговизна

проекта;

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

Модель спирального процесса разработки является наиболее распространенной в настоящее время. Самыми известными ее вариантами являются RUP (Rational Unified Process) от фирмы Rational и MSF (Microsoft Solution Framework).

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

1. Камаев, В. А., Костерин, В. В. Технологии программирования: Учебник / 2-е изд., перераб. и доп.– М.: Высшая школа, 2006, - 454 с.
2. Макаров, П. С. Операционные системы: архитектура и управление процессами: методические рекомендации. – Ульяновск: УлГТУ, 2008. – 77 с.
3. Макаренко, С. И. Операционные системы, среды и оболочки: учебное пособ. – Ставрополь: СФ МГГУ им. М. А. Шолохова, 2008. – 210 с.
4. Назаров, С. В. Архитектуры и проектирование программных систем: монография. — М.: ИНФРА-М, 2013. — 413 с.
5. Назаров, С. В., Белоусова, С. Н., Бессонова, И.А. [и др.]. Введение в программные системы и их разработку: Учебное пособие. 3-е изд. (эл.) — Национальный Открытый Университет «ИНТУИТ»; Саратов: Ай Пи Ар Медиа, 2020. — 649 с. – Текст электронный.
6. Одинцов, И. О. Профессиональное программирование. Системный подход.— 2-е изд. перераб. и доп. — СПб.: БХВ-Петербург, 2004. — 624 с.: ил.
7. Орлов, С. А. Программная инженерия. Учебник для вузов. 5-е издание обновленное и дополненное. Стандарт третьего поколения. – СПб.: Питер, 2016. – 640 с.: ил. – (Серия «Учебник для вызов»).
8. Шишов, О. В. Технология разработки программных продуктов [Электронный ресурс] URL: https://studfile.net/preview/7209950/ (дата обращения: 30.10.2020).
9. Современные операционные системы. Курс лекций. Лекция 1: Архитектура, назначение и функции операционных систем. Национальный Открытый Университет «ИНТУИТ» [Электронный ресурс] URL: https://intuit.ru/studies/courses/631/487/lecture/11048?page=1 (дата обращения: 02.11.2020).
10. Стандарт ISO/IEC 2382-1:1993. Термины и определения.
11. Стандарт ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes» [Электронный ресурс] URL: https://ru.wikipedia.org/wiki/ISO/IEC_12207:2008 (дата обращения: 27.10.2020).
12. Спиральная модель. Википедия — свободная энциклопедия [Электронный ресурс] URL: https://ru.wikipedia.org/wiki/Спиральная_модель (дата обращения: 01.11.2020).