11 Выделение и анализ требований
После получения общего представления о деятельности и целях организаций, в которых будет работать будущая программная система, и о ее предметной области, можно определить более четко, какие именно задачи система будет решать. Кроме того, важно понимать, какие из задач стоят наиболее остро и обязательно должны быть поддержаны уже в первой версии, а какие могут быть отложены до следующих версий или вообще вынесены за рамки области ответственности системы. Эта информация выявляется при анализе потребностей возможных пользователей и заказчиков.
Потребности определяются на основе наиболее актуальных проблем и задач, которые пользователи и заказчики видят перед собой. При этом требуется аккуратное выявление значимых проблем, определение того, насколько хорошо они решаются при текущем положении дел, и расстановка приоритетов при рассмотрении недостаточно хорошо решаемых, поскольку чаще всего решить сразу все проблемы невозможно.
Формулировка потребностей может быть разбита на следующие этапы.
Выделить одну-две-три основных проблемы.
Определить причины возникновения проблем, оценить степень их влияния и выделить наиболее существенные из проблем, влекущие появление остальных.
Определить ограничения на возможные решения.
Формулировка потребностей не должна накладывать лишних ограничений на возможные решения, удовлетворяющие им. Нужно попытаться сформулировать, что именно является проблемой, а не предлагать сразу возможные решения.
Например, формулировки "система должна использовать СУБД Oracle для хранения данных", "нужно, чтобы при вводе неверных данных раздавался звуковой сигнал" не очень хорошо описывают потребности. Исключением в первом случае может быть особая ситуация, например, если СУБД Oracle уже используется для хранения других данных, которые должны быть интегрированы с рассматриваемыми: при этом ее использование становится внешним ограничением. Соответствующие потребности лучше описать так: "нужно организовать надежное и удобное для интеграции с другими системами хранение данных", "необходимо предотвращать попадание некорректных данных в хранилище".
При выявлении потребностей пользователей анализируются модели деятельности пользователей и организаций, в которых они работают, для выявления проблемных мест. Также используются такие приемы, как анкетирование, демонстрация возможных сеансов работы будущей системы, интерактивные опросы, где пользователям предоставляется возможность самим предложить варианты внешнего вида системы и ее работы или поменять предложенные кем-то другим, демонстрация прототипа системы и др.
После выделения основных потребностей нужно решить вопрос о разграничении области ответственности будущей системы, т.е. определить, какие из потребностей надо пытаться удовлетворить в ее рамках, а какие — нет.
При этом все заинтересованные лица делятся на пользователей, которые будут непосредственно использовать создаваемую систему для решения своих задач, и вторичных заинтересованных лиц, которые не решают своих задач с ее помощью, но чьи интересы так или иначе затрагиваются ею. Потребности пользователей нужно удовлетворить в первую очередь и на это нужно выделить больше усилий, а интересы вторичных заинтересованных лиц должны быть только адекватно учтены в итоговой системе.
На основе выделенных потребностей пользователей, отнесенных к области ответственности системы, формулируются возможные функции будущей системы, которые представляют собой услуги, предоставляемые системой и удовлетворяющие потребности одной или нескольких групп пользователей (или других заинтересованных лиц). Идеи для определения таких функций можно брать из имеющегося опыта разработчиков (наиболее часто используемый источник) или из результатов мозговых штурмов и других форм выработки идей.
Формулировка функций должна быть достаточно короткой, ясной для пользователей, без лишних деталей. Например:
Все данные о сделках и клиентах будут сохраняться в базе данных.
Статус выполнения заказа клиент сможет узнать через Интернет.
Система будет поддерживать до 10000 одновременно работающих пользователей.
Расписание проведения ремонтных работ будет строиться автоматически.
Предлагая те или иные функции, нужно уметь аккуратно оценивать их влияние на структуру и деятельность организаций, в рамках которых будет использоваться ПО. Это можно сделать, имея полученные при анализе предметной области модели их текущей деятельности.
Имея набор функций, достаточно хорошо поддерживающий решение наиболее существенных задач, с которыми придется работать разрабатываемой системе, можно составлять требования к ней, представляющие собой детализацию работы этих функций. Соотношение между проблемами, потребностями, функциями и требованиями показано на рис. 4.6.
Рис. 4.6. Соотношение между проблемами, потребностями, функциями и требованиями
При этом часто нужно учитывать, что ПО является частью программно-аппаратной системы, требования к которой надо преобразовать в требования к программной и аппаратной ее составляющим. В последнее время, в связи со значительным падением цен на мощное аппаратное обеспечение общего назначения, фокус внимания переместился, в основном, на программное обеспечение. Во многих проектах аппаратная платформа определяется из общих соображений, а поддержку большинства нужных функций осуществляет ПО.
Каждое требование раскрывает детали поведения системы при выполнении ею некоторой функции в некоторых обстоятельствах. При этом часть требований исходит из потребностей и пожеланий заинтересованных лиц и решений, удовлетворяющих эти потребности и пожелания, а часть — из внешних ограничений, накладываемых на систему, например, основными законами той предметной области, в рамках которой системе придется работать, государственным законодательством, корпоративной политикой и пр.
Еще до перехода от функций к требованиям полезно расставить приоритеты и оценить трудоемкость их реализации и рискованность. Это позволит отказаться от реализации наименее важных и наиболее трудоемких, не соответствующих бюджету проекта функций еще до их детальной проработки, а также выявить возможные проблемные места проекта — наиболее трудоемкие и неясные из вошедших в него функций.
12 Сценарий использования, вариант использования, прецедент или же пользовательский сценарий (англ. Use Case) — в разработке программного обеспечения и системном проектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой. Методика сценариев использования применяется для выявления требований к поведению системы, известных также как функциональные требования.
В системном проектировании сценарии использования применяются на более высоком уровне чем в при разработке программного обеспечения, часто представляя цели заинтересованных лиц или миссии. На стадии анализа требований сценарии использования могут быть преобразованы в ряд детальных требований и задокументированы с помощью диаграмм требований SysML или других подобных механизмов.
Цели сценариев использования
«Каждый сценарий использования сосредотачивается на описании того, как достигнуть цели или задачи. Для большинства программных проектов это означает, что потребуется множество сценариев использования чтобы определить необходимый набор свойств новой системы. Степень формальности программного проекта и его стадии будет влиять на необходимый уровень детализации, для каждого сценария использования.»
Сценарии использования не должны путаться с понятием свойств системы (англ. Feature). Сценарий использования может быть связан с одним или более свойством системы, и свойство может быть связано с одним или более сценарием использования.
Сценарий использования определяет взаимодействия между внешними агентами и системой, направленные на достижение цели. Актер (англ. Actor) представляет собой роль, которую играет человек или вещь, взаимодействуя с системой. Тот же самый человек, использующий систему, может быть представлен как различные актеры, потому что они играют различные роли. Например, «Джек» может играть роль Клиента использующего Банкомат, чтобы забрать наличные деньги, или играть роль Работника Банка, использующего систему для пополнения банкомата купюрами.
Сценарии использования рассматривают систему как «черный ящик», и взаимодействия с системой, включая системные ответы, описываются с точки зрения внешнего наблюдателя. Это — преднамеренная политика, потому что это вынуждает автора сосредоточиться на том, что система должна сделать, а не, как это должно быть сделано, и позволяет избегать создания предположений о том, как функциональные возможности будут реализованы.
Сценарии использования могут быть описаны на абстрактном уровне (деловой сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования). Различия между ними — в деталях.
Деловой сценарий использования не затрагивает технологий, рассматривает систему как «черный ящик» и описывает бизнес-процесс, который используется деловыми актерами (людьми, или системами, внешними к бизнесу) для достижения своих целей (например, обработка оплаты, одобрение авансового отчета, управляет корпоративным недвижимым имуществом). Деловой сценарий использования описывает процесс, ценный для делового агента, описывает что именно делает процесс.
Системный сценарий использования обычно описывается на уровне функций системы (например, создайте ваучер), и определяет функцию или сервис, предоставляемые системой для пользователя. Системный сценарий использования описывает что актер может сделать взаимодействуя с системой. По этой причине рекомендуется, чтобы системные случаи использования началась с глагола (например, создайте ваучер, выберите платежи, отмените ваучер).
Сценарий использования должен:
Описывать что именно система должна сделать, чтобы актер достиг своей цели.
Не затрагивать деталей реализации.
Иметь достаточный уровень детализации.
Не описывать пользовательские интерфейсы и экраны. Это делается во время дизайна пользовательского интерфейса.
Уровень детализации
Алистер Кокберн в книге «Написание эффективных сценариев использования» выделил три уровня детализации сценариев использования:
Краткий сценарий использования
состоит из нескольких предложений. Он может быть легко вставлен в ячейку электронной таблицы, позволяя записать в соседних столбцах приоритет, продолжительности, техническую сложность и другие параметры.
Обычный сценарий использования
состоит из нескольких параграфов текста, подытоживающих сценарий использования.
Полностью детализированный сценарий использования
формальный документ, основанный на подробном шаблоне с различными разделами. Именно этот вариант подразумевается в большинстве случаев под понятием сценария использования.
13 Ка́чество програ́ммного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001, согласно которому качество есть «степень соответствия присущих характеристик требованиям».
Содержание
[убрать]
1 Качество исходного кода
2 Факторы качества
3 С точки зрения пользователя
4 См. также
5 Ссылки
Качество исходного кода
Качество кода может определяться различными критериями. Некоторые из них имеют значение только с точки зрения человека. Например, то, как отформатирован текст программы, совершенно не важно для компьютера, но может иметь серьёзное значение для последующего сопровождения. Многие из имеющихся стандартов оформления кода, определяющих специфичные для используемого языка соглашения и задающие ряд правил, улучшающих читаемость кода, имеют своей целью облегчить будущее сопровождение ПО, включающее отладку и обновление. Существуют и другие критерии, определяющие, «хорошо» ли написан код, например, такие, как структурированность — степень логического разбиения кода на ряд управляемых блоков.
Читаемость кода
Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения и портируемости
Низкая сложность кода
Низкое использование ресурсов: памяти и процессорного времени
Корректная обработка исключительных ситуаций
Малое число предупреждений при компиляции и линковке
Методы улучшения качества кода: рефакторинг.
Факторы качества
Фактор качества ПО — это нефункциональное требование к программе, которое обычно не описывается в договоре с заказчиком, но, тем не менее, является желательным требованием, повышающим качество программы.
Некоторые из факторов качества:
понятность
Назначение ПО должно быть понятным, из самой программы и документации.
полнота
Все необходимые части программы должны быть представлены и полностью реализованы.
краткость
Отсутствие лишней, дублирующейся информации. Повторяющиеся части кода должны быть преобразованы в вызов общей процедуры. То же касается и документации.
портируемость
Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.
согласованность
По всей программе и в документации должны использоваться одни и те же соглашения, форматы и обозначения.
сопровождаемость
Насколько сложно изменить программу для удовлетворения новых требований. Это требование также указывает, что программа должна быть хорошо документирована, не слишком запутана, и иметь резерв роста по использованию ресурсов (память, процессор).
тестируемость
Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности.
удобство использования
Простота и удобство использования программы. Это требование относится прежде всего к интерфейсу пользователя.
надёжность
отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок:
структурированность
эффективность
Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач.
безопасность
С точки зрения пользователя
Помимо технического взгляда на качество ПО, существует и оценка качества с позиции пользователя. Для этого аспекта качества иногда используют термин «юзабилити». Довольно сложно получить оценку юзабилити для заданного программного продукта. Наиболее важные из вопросов, влияющий на оценку:
Является ли пользовательский интерфейс интуитивно понятным?
Насколько просто выполнять простые, частые операции?
Насколько легко выполняются сложные операции?
Выдаёт ли программа понятные сообщения об ошибках?
Всегда ли программа ведёт себя так как ожидается?
Имеется ли документация и насколько она полна?
Является ли интерфейс пользователя само-описательным/само-документирующим?
Всегда ли задержки с ответом программы являются приемлемыми?
14 Тестирование (Testing) - совокупность действий проводимых над объектом тестирования, а именно применение различных видов тестирования, для получения результата о его соответствии поставленным требованиям.
Контроль качества (Quality Control) - совокупность мероприятий проводимых в процессе разработки, для постоянного получения исчерпывающей информации о соответствии объекта тестирования поставленным требованиям. Сюда входят Test Management, Test Analysis, Test Design, Testing and etc.
Обеспечение качества (Quality Assurance) - совокупность мероприятий, охватывающих все подразделения компании, предпринимаемых на разных стадиях разработки, для улучшения качества выпускаемого продукта. Сюда входят, оптимизация имеющихся процессов: бизнес-анализа, проектирования, разработки, тестирования и т.п.
QA (Quality Assurance, Обеспечение качества) - совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации ПО информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения качества выпускаемого продукта.
QC (Quality Control, Контроль качества) - совокупность действий проводимых над объектом тестирования в процессе разработки для получения информации об актуальном состоянии объекта тестирования в разрезах: "готовность Продукта к выпуску", "Соответствие зафиксированным требованиям", "Соответствие заявленному уровню качества продукта".
Software Testing является одной из техник контроля качества и включает в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).
15 Методы и техники определения показателей качества на основе симуляции работы ПО с помощью моделей разного рода.К этому виду относятся проверка на моделях (model checking), а также прототипирование (макетирование), используемое для оценки качества принимаемых решений.