birmaga.ru
добавить свой файл

1

Работа с требованиями к ПО. Постановка задачи

Тема этого курса — формальные методы разработки ПО.

Зачем нужны эти самые формальные методы?

Их цель — обеспечить эффективное построение «правильного», качественного ПО.

Что такое качественное программное обеспечение?

Если попросить группу людей высказать своё мнение на этот счет, можно получить следующие варианты ответов:


  • Легко использовать

  • Хорошая производительность

  • Нет ошибок

  • Не портит пользовательские данные при сбоях

  • Можно использовать на разных платформах

  • Может работать 24 часа в сутки и 7 дней в неделю

  • Легко добавлять новые возможности

  • Удовлетворяет потребности пользователей

  • Надежное

  • Хорошо документировано

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

Приведенные ответы показывают, что качество ПО может быть описано только большим количеством разнородных характеристик.

Общие принципы разработки качественных продуктов во всех отраслях экономики регулируются набором стандартов ISO 9000. В последние годы многие организации во всем мире используют его рекомендации для повышения качества своих продуктов и услуг. ISO 9000 был принят Европейским сообществом в качестве документа, регламентирующего требования к работе коммерческих и правительственных организаций. Организации, желающие вести бизнес в Европе, как правило, должны иметь сертификат ISO 9000. Для сертификации требуется оценка «на месте» уполномоченным ISO чиновником. Прошедшие оценку компании извещаются о том, что они будут периодически подвергаться повторной оценке, чтобы подтвердить свой сертификат.


Понятие качества ПО определяется стандартом ISO 9126.

Ниже приведен полный список атрибутов качества ПО по стандарту ISO 9126:2001.


  • Функциональность («что делает ПО»)

    • Пригодность к определенной работе(suitability)

    • Точность, правильность (accuracy)

    • Способность к взаимодействию (interoperability)

    • Соответствие стандартам и правилам (compliance)

    • Защищенность (security)

  • Надежность («насколько надежно ПО работает»)

    • Зрелость, завершенность (обратна к частоте отказов) (maturity)

    • Устойчивость к отказам (fault tolerance)

    • Способность к восстановлению работоспособности при отказах (recoverability)

    • Соответствие стандартам надежности (reliability compliance, добавлен в 2001)

  • Практичность, удобство использования («насколько удобно пользоваться ПО»)

    • Понятность (understandability)

    • Удобство обучения (learnability)

    • Работоспособность (operability)

    • Привлекательность (attractiveness, добавлен в 2001)

    • Соответствие стандартам практичности (usability compliance, добавлен в 2001)

  • Эффективность («насколько эффективно работает ПО»)

    • Временные характеристики (time behaviour)

    • Использование ресурсов (resource utilisation)

    • Соответствие стандартам эффективности (efficiency compliance, добавлен в 2001)

  • Сопровождаемость («насколько удобно вносить изменения и поправки в ПО»)

    • Анализируемость (analyzability)

    • Изменяемость, удобство внесения изменений (changeability)

    • Риск возникновения неожиданных эффектов при внесении изменений (stability)

    • Контролируемость, удобство проверки (testability)
    • Соответствие стандартам сопровождаемости (maintainability compliance, добавлен в 2001)


  • Переносимость, мобильность («насколько удобно переносить ПО в другое окружение»)

    • Адаптируемость (adaptability)

    • Устанавливаемость, удобство установки (installability)

    • Способность к сосуществованию с другим ПО (coexistence)

    • Удобство замены другого ПО данным (replaceability)

    • Соответствие стандартам переносимости (portability compliance, добавлен в 2001)

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

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

  • Насколько оно должно быть надежно. Примеры:
    Работать 7 дней в неделю и 24 часа в сутки;
    Допускается неработоспособность в течение не более 3 часов в год.

  • Насколько им должно быть удобно пользоваться. Примеры:
    Покупатель должен легко находить нужный ему товар;
    Инженер по специальности «строительство мостов» должен легко понимать, как пользоваться системой.

  • Насколько оно должно быть эффективно. Примеры:
    Поддерживать обслуживание до 10000 запросов в секунду;
    Время отклика на запрос при максимальной загрузке не должно превышать 3 с;
    Время реакции на изменение параметров процесса производства не должно превышать 0.1 с;
    На обработку одного запроса не должно тратиться более 10 MB оперативной памяти.

  • Насколько удобно должно быть его сопровождение. Примеры:

    Добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;

    Добавление поддержки нового процесса производства не должно занимать более 24 человеко-месяцев.


  • Насколько оно должно быть переносимо и заменяемо. Примеры:
    ПО должно работать на операционных системах Linux, Windows XP и Mc OS X;
    ПО должно работать с документами в форматах MS Word;
    ПО должно сопрягаться с существующей системой записи данных о заказах.

Как контролировать качество системы? Как точно узнать, что программа делает именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна, переносима, удобна в использовании?

Ответы на этот вопрос можно получить с помощью процессов верификации и валидации:

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

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

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

Эффективность верификации и валидации, как и эффективность разработки ПО зависит от точности и корректности формулировки требований к программному продукту.

Все требования обычно делят на три группы:

  • функциональные требования к ПО;

  • нефункциональные требования к ПО;

  • ограничения проектирования.

Функциональные требования описывают, что делает система, это требования к первой составляющей качества — функциональности. Эти требования обычно ориентированы на действия (Когда пользователь нажимает кнопку «Обработать заказ», система сохраняет данные заказа в БД и определяет его статус как «В очереди на обработку»).

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



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

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

Можно указать следующие источники ограничений проектирования:


  • операционные среды

  • совместимость с существующими системами

  • прикладные стандарты

  • корпоративные практические наработки и стандарты.

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

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

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

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




Анализ проблемы — это процесс осознания реальных проблем и потребностей пользователя и предложения решений для удовлетворения этих потребностей.

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



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



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


  • У автомобиля будут автоматические стеклоподъемники

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

  • Необходимо предусмотреть возможность ввода заказов через Интернет

  • Будет поддерживаться автоматический цикл двойной сварки

Эти описания называются «функциями» (features) создаваемой системы.

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

Этими требованиями являются требования к программному обеспечению (software requirements).


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


Эти программные требования являются исходными данными для построения самого ПО и для проведения его контроля.

Пример: потребности – функции – программные требования


Контроль качества строительства магистральных газопроводов.

Основная проблема заказчика — большой ущерб от аварий. Как его снизить? Что можно сделать для этого? Рассмотрим сначала причины аварий и факторы, влияющие на причиняемый ими ущерб.



Анализ влияния этих факторов на ущерб от аварий дает такую картину.





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

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

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

  2. Сбор, хранение и возможность просмотра данных о сварочных работах.

  3. Сбор, хранение и возможность просмотра данных о профилактических работах.

  4. Сбор, хранение и возможность просмотра данных об авариях.

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

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


  8. И т.д.

Для преобразования функций в требования к ПО следует провести их дальнейшую конкретизацию.

  1. Функция 5 может быть раскрыта в такое требование:
    Пользователь указывает в списке аварий две аварии и нажимает кнопку «Сопоставить».
    Система выдает список общих атрибутов указанных аварий.
    Атрибутами аварии считаются следующие данные:

    1. Место (км по линии газопровода, номер участка, название газотранспортного предприятия)

    2. Дата (день, месяц, год, час, минута)

    3. Данные об эксплуатации (бригада обходчиков, список 5-ти последних обследований, с их датами, видами проведенного контроля и результатами)

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

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

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

  2. Функция 6 раскрывается в такое требование:
    Пользователь выделяет линейный участок газопровода (между двумя газораспределительными станциями) и нажимает кнопку «Расписание».
    Система выдает расписание проведения дефектоскопического контроля на данном участке на полгода, определяющее, когда и с какого пункта обслуживания посылать снаряд для контроля какого контрольного участка (контрольный участок — это участок длиной не более 3-5 км, на концах которого имеются краны для перекрытия подачи газа и входы — ответвления труб для ввода снаряда в газопровод и его вывода оттуда).
    Входными данными для составления расписания являются следующие:
    1. Количество и расположение на данном участке пунктов обслуживания (для каждого — км по линии газопровода), на которых хранится и обслуживается по одному дефектоскопическому снаряду.

    2. Расположение контрольных участков на данном линейном участке.

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

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