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

Рисунок 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) программной системы понимается последовательность и взаимосвязь процессов и выполняемых специалистами действий и задач на всем протяжении ЖЦ ПС. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.

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

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

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