Ис. Конспект лекций Маглинец Ю. А. Красноярск сфу 2007 Введение. Понятие и классификация требований
 Скачать 0.88 Mb.
|
|
Определение понятия требования Л.Новиков в русской редакции нотации RUP [15] приводит следующее определение: «Требование – это условие или возможность, которой должна соответствовать система». В IEEE Standard Glossary of Software Engineering Terminology (1990) [7] данное понятие трактуется шире. Требование – это: 1. условия или возможности, необходимые пользователю для решения проблем или достижения целей; 2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам; 3. документированное представление условий или возможностей для пунктов 1 и 2 (конец цитаты). Введём ещё одно определение. Требования – это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы. Первичные данные поступают из различных источников, характеризуются противоречивостью, неполнотой, нечёткостью, изменчивостью. Требования нужны в частности для того, чтобы Разработчик мог определить и согласовать с Заказчиком временные и финансовые перспективы проекта автоматизации. Поэтому значительная часть требований должна быть собрана и обработана на ранних этапах создания АИС. Однако собрать на ранних стадиях все данные, необходимые для реализации АИС, удаётся только в исключительных случаях. На практике процесс сбора, анализа и обработки растянут во времени на протяжении всего жизненного цикла АИС, зачастую нетривиален и содержит множество подводных камней; подробнее о процессе – в лекциях 4-8. Классификация требований Существует значительное количество различных методов классификации требований [8-13], наиболее существенные из которых будут рассмотрены в лекции. Требования к продукту и процессу Требования к продукту. В своей основе требования – это то, что формулирует заказчик. Цель, которую он преследует – получить хороший конечный продукт: функциональный и удобный в использовании. Поэтому требования к продукту являются основополагающим классом требований. Более подробно требования к продукту детализируются в следующих ниже классификациях. Требования к проекту. Вопросы формулирования требований к проекту, т.е. к тому, как Разработчик будет выполнять работы по созданию целевой системы, казалось бы, не лежат в компетенции Заказчика. Без регламентации процесса Заказчиком легко можно было бы обойтись, если бы все проекты всегда выполнялись точно и в срок. Однако, к сожалению, мировая статистика результатов программных проектов говорит об обратном. Заказчик, вступая в договорные отношения с Разработчиком, несёт различные риски, главными из которых является риск получить продукт с опозданием, либо ненадлежащего качества. Основные мероприятия по контролю и снижению риска – регламентация процесса создания программного обеспечения и его аудит. Насколько подробно Заказчику следует регламентировать требования к проекту – вопрос риторический. Ответ на него зависит о множества факторов, таких, как ценность конечного продукта для Заказчика, степень доверия Заказчика к Разработчику, сумма подписанного контракта, увязка срока сдачи продукта в эксплуатацию с бизнес-планами Заказчика и т.д. Однако, со всей определённостью можно сказать следующее: 1) регламентация процесса Заказчиком позволяет снизить его риски; 2) мероприятия Заказчика по регламентации процесса приводят к дополнительным накладным расходам. Требуется найти разумный компромисс между степенью контроля рисков и величиной расходов. В качестве требований к проекту могут быть внесён регламент отчётов Разработчика, совместных семинаров по оценке промежуточных результатов, определены характеристики компетенций участников рабочей группы, исполняющих проект, их количество, указана методология управления проектом. Ниже сформулирован пример формулировки требования к оффшорному проекту (Заказчик и Разработчик физически находятся в разных государствах) – в этой ситуации Заказчику требуется жёсткий контроль над Разработчиком. 1) Разработчик представляет Заказчику согласованный план работ c детализацией (WorkBreakdownStructure - WBS) с точностью до конкретных исполнителей. 2) Разработчик осуществляет ежедневные сборки, регрессионное тестирование компонент разрабатываемого продукта и тестирование продукта в целом. 3) Все управленческие и проектные артефакты, исходные коды и тестовые примеры размещаются в режиме online в интегрированной среде разработки Rational ClearCase с возможностью для Заказчика осуществления online-мониторинга на базе web-технологий. Уровни требований Внедрение ИС на предприятии всегда преследует конкретные бизнес-цели – такие, как, например, повышение прозрачности бизнеса, сокращение сроков обработки информации, экономия накладных расходов и т.д. Современные информационные системы – это крупные программные системы, содержащие в себе множество модулей, функциональных, интерфейсных элементов, отчётов и т.д. Как охватить единым взором такие разнородные вещи, как цели, преследуемые топ-менеджером предприятия Заказчика, описание интерфейса пользователя и характеристики модуля, осуществляющего расчёт себестоимости изделия? К счастью, человечество уже давно изобрело приёмы борьбы со сложностью, широко применяемые в моделировании сложных объектов – абстракцию и декомпозицию. Применительно к дисциплине анализа требований к программным системам эти принципы работают следующим образом. Требования разделяются по уровням. Уровни требований связаны, с одной стороны, с уровнем абстракции системы, с другой – с уровнем управления на предприятии. Обычно выделяют три уровня требований. На верхнем уровне представлены так называемые бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия. Следующий уровень – уровень требований пользователей (user requirements). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований. Третий уровень – функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удалён и перемещён с участка на участок. Существуют объективные противоречия между требованиями различных уровней. Так, очевидным бизнес-требованием является требование о полноте информации, собираемой на рабочих местах пользователей в единую базу данных. Чем полнее информация – тем глубже база для анализа деятельности и принятия решений. С другой стороны, конкретному пользователю системы вполне может быть достаточно использования только той части информации, которая влияет на выполнение его основных функций. Важные правила внедрения и использования АИС на предприятии – «Одна точка сбора», «Данные собираются там, где они появляются». Использование этих правил позволяет избежать затрат на необоснованное дублирование информации и, что важнее – потерь от ошибок учёта, неизбежно возникающих при дублировании точек ввода. Внедрение АИС на предприятии приводит к необходимости оснащения всех точек ввода информации автоматизированными рабочими местами (АИС), обучению персонала и, зачастую, оптимизации и повышению уровня формализации рабочих процессов, выполняемых персоналом. Поэтому внедрение АИС – непростой процесс, часто требующий «перекройки человеческого материала» и встречающий сопротивление со стороны пользователей, которые не готовы, либо не хотят работать по-новому. Системные требования и требования к программному обеспечению Существуют различные трактовки понятия «Системные требования» (system requirements). К. Вигерс формулирует данный термин, как «высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть системе» [8]. При этом под системой понимается программная, программно-аппаратная, либо человеко-машинная система. Данная система является сложной, структурированной системой и системные требования являются подмножеством функциональных требований к продукту. В данное подмножество целесообразно относить наиболее важные, существенные требования, которые относятся в целом к системе и не содержат избыточной детализации. INCOSE (International Council on Systems Engineering) даёт более детальное определение системы: «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы». Таким образом, происходит разделение между системными требованиями, как обобщающему понятию и требованиями к программному обеспечению, как выделенному подмножеству системных требований, направленных исключительно на программные компоненты системы. Этот же подход прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99 [14]: работы, связанные с системой в целом и с программным обеспечением выделяются в отдельные группы в целях удобства оперирования. В практике компьютерной инженерии бытует другой, более узкий контекст использования данного понятия: под системными требованиями в узком смысле понимается требования, выдвигаемые прикладной программной системой (в частности – информационной) к среде своего функционирования (системной, аппаратной). Пример таких требований – тактовая частота процессора, объём памяти, требования к выбору операционной системы. Функциональные, нефункциональные требования и характеристики продукта Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос «что должна делать система» в тех или иных ситуациях. Функциональные требования определяют основной «фронт работ» Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику. Функциональные требования записываются, как правило, при посредстве предписывающих правил: «система должна позволять кладовщику формировать приходные и расходные накладные». Другим способом являются так называемые варианты использования (uses cases) – популярный и весьма продуктивный способ представления требований. Это – основной, определяющий вид требований, который будет рассматриваться на протяжении всего лекционного курса. Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс [8] выделяет следующие основные группы нефункциональных требований: Внешние интерфейсы (External Interfaces), Атрибуты качества (Quality Attributes), Ограничения (Constraints). Среди внешних интерфейсов в большинстве современных АИС наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы). Основные атрибуты качества: Применимость, Надежность, Производительность, Эксплуатационная пригодность, достаточно хорошо раскрыты в модели FURPS (см. ниже). Ограничения [8] - формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам (конец цитаты). Характеристики продукта. К.Вигерс [8] формулирует характеристику, «фичу» (feature), как набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели. Существует и более общий взгляд на данное понятие 2 : «features могут быть как относящимся к функциональным, так и к нефункциональным требованиям и могут изменяться от версии к версии продукта». С.Орлик в [12] отмечает, что «с точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными». Роль характеристик проявляется в первую очередь в области маркетинга: не всякий потенциальный потребитель продукта станет читать его функциональные описания, а набор ключевых характеристик, характеризующих конкурентные преимущества, можно сделать лаконичным и уместить на одной странице рекламной листовки, либо напечатать на компакт-диске. Классификация RUP В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990 [7]. Акроним FURPS обозначает следующие категории требований: Functionality (Функциональность) Usability (Применимость) Reliability (Надёжность) Performance (Производительность) Supportability (эксплуатационная пригодность). Символ «+» расширяет FURPS-модель, добавляя к ней: ограничения проекта, требования выполнения, требования к интерфейсу, физические требования, часть из которых уже была рассмотрена выше. Кроме того, в спецификациях RUP выделяются такие категории требований, как требования, указывающие на необходимость согласованности с некоторыми юридическими и нормативными актами; требования к лицензированию, требования к документированию. Методологии и стандарты, регламентирующие работу с требованиями Среди основополагающих нормативных документов в области работы с требованиями можно выделить следующие. 1. Разработки IEEE: IEEE 1362 “Concept of Operations Document”. 2 Kurt Bittner, Ian Spence. Use Case Modeling, 2002. IEEE 1233 «Guide for Developing System Requirements Specifications». IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications» IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12- 1990 IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004. 2. Отечественные ГОСТ: ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания. ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению. Литература к лекции 1. Макарова Н.В. Информатика: Учебник. - М.: Финансы и статистика, 2003. - 768 с. 2. ERP системы. Современное планирование и управление ресурсами предприятия. Выбор, внедрение, эксплуатация/Дэниел О’Лири;[Пер. с англ. Ю.И.Водопьяновой]. – М.: ООО «Вершина», 2004. – 272 с. 3. Меняев М.Ф. Информационные технологии управления: Учебное пособие: В 3 кн.: Книга 3: Системы управления организацией. – М.: Омега-Л, 2003. – 464 с. 4. Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие. – М.: Гелиос АРВ, 2002. – 368 с., ил. 5. Б.Н. Гайфуллин, И.А. Обухов. Автоматизированные системы управления предприятиями стандарта ERP/MRPII. Производственное издание. – М. «Богородский печатник», 2001, 104 с. 6. Петров В. Н. Информационные системы. – СПб.: Питер, 2002. - 688 с. 7. IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990 8. Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил. 9. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002. 10. Алистер Коберн. Современные методы описания функциональных требований к системам. М.: издательство «Лори», 2002. – 263 с. 11. Мацяшек Лешек. Анализ требований и проектирование систем. Разработка информационных :с Диалектика-Вильямс 12. Орлик С., Булуй Ю. Введение в программную инженерию и управление жизненным циклом ПО Программная инженерия. Программные требования. Copyright © Сергей Орлик, 2004-2005. http://www.sorlik.ru/swebok/3-1-software_engineering_requirements.pdf 13. IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004. – http://www.swebok.org 14. ГОСТ Р ИСО/МЭК 12207/99. Государственный стандарт РФ. Информационная технология. Процессы жизненного цикла информационных систем. Издание официальное. – М., 1999. 15. Л.Новиков. Введение в Rational Unified Process. http://www.interface.ru/rational/interface/151199/rup/main.htm 16. Белые страницы MSF. http://www.microsoft.com/rus/msdn/msf 17. Analyzing requirements and defining Microsoft .Net solution architectures 2000 г. 491 стр. Microsoft Press. 18. Введение в Rational Unified Process/ Ф. Кратчен – СПб.: Вильямс, 2002. – 240 с. 19. Унифицированный процесс разработки программного обеспечения/ А. Якобсон, Г. Буч, Дж. Рамбо – СПб.: Питер , 2002. – 496 с . 20. IEEE 1362 - Concept of Operations Document 21. IEEE 1233 - Guide for Developing System Requirements Specifications. 22. IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications» 2. Требования и их свойства. Процесс анализа требований План лекции Свойства требований Полнота Ясность Корректность и согласованность (непротиворечивость) Верифицируемость Необходимость и полезность при эксплуатации Осуществимость Трассируемость Упорядоченность по важности и стабильности. Наличие количественной метрики Каких требований не должно быть Процесс анализа требований Рабочий поток анализа требований Кто создаёт и использует требования Организация работы с требованиями на примере MSF Ф. Брукс в своём, теперь уже ставшим классическим, эссе 3 , следующим образом охарактеризовал роль требований в разработке программного обеспечения. Строжайшее и единственное правило построения систем программного обеспечения (ПО) – решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно (конец цитаты). Наука извлечения и формализации качественных (иногда говорят «хороших», «правильных») требований носит во многом эмпирический характер. Однако, в практике разработки программных систем накопились определённые представления о том, какими свойствами должны обладать требования к программной системе. Это: полнота, ясность, корректность, согласованность, верифицируемость, необходимость, полезность при эксплуатации, осуществимость, модифицируемость, трассируемость, упорядоченность по важности и стабильности, наличие количественной метрики. Большинство из этих свойств раскрыто в первом разделе стандарта IEEE [1] и широко обсуждается в работах [8,9]. Рассмотрим указанные выше свойства подробнее. |