Теоретический материал. Определение требований к программным продуктам

Определение требований к программным продуктам. Архитектура ПО

Лекция №8

Цели занятия:

Обучающая: получить представление о видах требований к программным продуктам и их назначении; получить представление о понятии «архитектура программного обеспечения», видах архитектур

Ведущий метод обучения: объяснительно-иллюстративный.

Форма занятия: лекция.

Оснащение занятия: конспект лекции, презентации.

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

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

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

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

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

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

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

Функциональная спецификация состоит из трех частей:

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

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

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

Эксплуатационные требования

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

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

2. Универсальность – обеспечение правильной работы при любых допустимых данных и защиты от неправильных данных. Также, как в предыдущем случае, доказать универсальность программы невозможно, поэтому имеет смысл говорить о степени ее универсальности.

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

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

5. Точность результатов – обеспечение погрешность результатов не выше заданной. Величина погрешности зависит от точности исходных данных, степени адекватности используемой модели, точности выбранного метода и погрешности выполнения операций в компьютере. Жесткие требования к точности предъявляют системы навигации и системы управления технологическими процессами.

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

7. Программная совместимость – возможность совместного функционирования с другим программным обеспечением. Чаще всего в данном случае речь идет и функционировании программы под управлением заданной операционной системы.

8. Аппаратная совместимость – возможность совместного функционирования с некоторым оборудованием. Это требование формулируют в виде минимально возможной конфигурации оборудования, на котором будет работать данное программное обеспечение. Если предполагается возможность нестандартного оборудования, то для него должны быть описаны интерфейсы.

9. Эффективность – использование минимально возможного количества ресурсов технических средств (например, времени микропроцессора, объема оперативной памяти и пр.). Эффективность оценивается по каждому ресурсу отдельно, поэтому требования эффективности часто противоречат друг другу.

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

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

12. Реентерабельность – возможность «параллельного» использования несколькими процессами. Чтобы удовлетворить этому требованию, необходимо создавать копию данных, изменяемых программой, для каждого процесса.

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

Дата добавления: 2014-01-05