Файл: Виды программного обеспечения. Основные требования, предъявляемые к программному обеспечению (Основные виды программного обеспечения).pdf

- модульность (выполнение условия позволяет снизить расходы по изменениям функциональной возможности системы за счет варьирования конфигурации ее отдельных элементов) [6];

- открытость (требование, направленное на обеспечение системы взаимодействовать с другим программным обеспечением по определенным стандартам) бинарная совместимость с предыдущими приложениями "что позволяет взаимодействовать с унаследованными системами;

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

- независимость от платформы (ограниченное одной платформой применения накладывает ограничения на приобретение систем в будущем) [5].

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

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

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

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

Построив применения на основе указанной инфраструктуры, компании всего мира смогли получить;

- неожиданно высокие доходы по своим инвестициям в информационные технологии);

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

- наличие эффективной системы восстановления частичной работоспособности системы в форс-мажорных ситуациях и т.д. [2]

Классификация требований к программному обеспечению и программных систем:

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

Не функциональные - характеристики системы и ее окружения, ограничения на функции, но не поведение [13].

Функциональные и нефункциональные требования предметной области - характеристики предметной области эксплуатации системы.

2.2. Функциональные и нефункциональные требования

Функциональные требования к ПС [1] - это те требования, которые отвечают на вопрос: "что делает система?" или "должна делать система?". Это перечисление всех основных функций обработки входящих и представления исходных данных, которые должны быть реализованы в ВС. Они описывают главную функциональность системы. Функциональные системные требования также называют набором взаимосвязанных вариантов использования ПО или прецедентов.

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

Актер (Actor) - сущность, имеет поведение: например, человек (пользователь), отдельный программный компонент или другая программная система [8].

Сценарий (Scenario) - последовательность действий или взаимодействий между актером и ПС [5].

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

1) Свободная форма описывается неформальный стиль описания. Описание прецедента занимает несколько абзацев и охватывает различные возможные сценарии.

2) Краткое описание - аннотация в виде одного абзаца. Она описывает только главный успешный сценарий.

3) Развернутое описание - при таком подходе подробно описываются все шаги и варианты развития сценария.

В нотации UML - функциональные требования описывают с помощью диаграммы прецедентов (Use Case Diagram).

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

Нефункциональные требования к ПО [9] отвечают на вопрос: "как та или иная ПС реализует функциональные требования?». К этим требованиям относятся следующие шесть атрибутов качества ПО:

1. Производительность (perfomance) - свойство ПС выполнять причиненные функции за определенный промежуток времени.

2. Надежность (reliability) - свойство ПС обрабатывать данные с заданным уровнем отказов и ошибок.

3. Масштабируемость (scaleability) - свойство ПС сохранять производительность и надежность в заданных пределах в условиях значительного роста числа пользователей и / или аппаратной платформы системы; это предполагает влияние увеличения числа операторов-пользователей, так и возможность увеличения числа технических средств (датчиков, контроллеров, терминалов и т. д.), данные из которых должны быть обработаны в ВС с заданными значениями производительности и надежности [4].

4. Удобство использования (usability) - эта характеристика показывает, насколько данная ПС соответствует таким критериям конечного пользователя как:

- понятность функций интерфейса;

- возможность изучения системы;

- эргономичность интерфейса [1].

5. Сопровождение (maintenancability) - свойства ПС, характеризуются следующими атрибутами:

- анализ исходного текста;

- возможность внесения изменений (возможность конфигурирования)

- тестирование исходного кода.

6. Переносимость (portability) - свойство ПС корректно функционировать не только на исходной платформе, но также иметь возможность быть использованной на другой операционной или аппаратной платформе [2].

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

Ниже будут рассмотрены основные атрибуты качества, необходимо положить в основу будущего программного обеспечения [6].

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

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

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

В-четвертых, необходимо обеспечить достаточную скорость расчета поставленных задач, поскольку решение задач многомерной оптимизации очень ресурсомиске [10].

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

1) удобство;

2) надежность;

3) сопровождение;

4) производительность.

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

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

2. Обработка данных:

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

- программа должна обеспечить поиск уже готовых шаблонов геометрических объектов;

- программа должна обеспечить получение необходимых данных для работы в удобном формате;

- программа должна обеспечить возможность сохранения отдельных объектов пользователем в удобном формате данных;

- программа должна обеспечить возможность сохранения программных решений пользователем в удобном формате данных;

- программа должна обеспечить возможность повторного использования программных решений и сохранившихся объектов [5].

3. Математические методы:

- необходимо реализовать алгоритм нахождения функции плотного размещения объектов;

- необходимо реализовать алгоритм нахождения функции плотного размещения объектов с учетом анизотропии геометрических объектов;

- алгоритм должен быстро и надежно рассчитывать поставленную задачу [2].

Ниже представлена UML-диаграмма прецедентов, отражающая функциональные требования.

Рисунок 2.1 - Диаграмма вариантов использования [2]

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

2.3. Принципы построения программного обеспечения

Процесс предоставления архитектуры, компонентов, интерфейсов и других характеристик системы или ее компонентов называется проектированием. Результат процесса проектирования – дизайн [4]. Как процесс, проектирования является инженерная деятельность в рамках жизненного цикла, в которой должным образом анализируются требования для создания описания внутренней структуры программного обеспечения, которая является основной для конструирования программного обеспечения. Программный дизайн должен описывать архитектуру программного обеспечения, то есть представлять декомпозиции программной системы в виде организованной структуры компонент и интерфейсов между компонентами. Важнейшей характеристикой готовности дизайна является тот уровень детализации компонентов, который позволяет заняться их конструированием [8].

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

- Архитектурный и высокоуровневый дизайн - описание высокоуровневой структуры и организации компонентов системы;

- Детализированная архитектура - описание каждого компонента в том объеме, который необходим для конструирования.

В 1999 году Том ДеМарко предложил терминологическое разделение различных видов дизайна:

D - дизайн - декомпозиция структуры программного обеспечения в виде набора фрагментов или компонент;

FP - дизайн - семейство архитектурных представлений, основанных на шаблонах;

I - дизайн - создание высокоуровневой концепции; данный вид дизайна является результатом процесса анализа требований и их трансформации в подходы к реализации [7].

Если рассматривать данную область знать в терминах ДеМарко, то проектирование программного обеспечения в понимании программной инженерии может содержать в себе только D-дизайнта FP- дизайн. И-дизайн относится к работе с программными требованиями.

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