Proektirovanie_ChMI_AT-13_-1_Chast_1
.pdf
Y - множество управляемых входных факторов.
Z - множество неуправляемых входных факторов, учитываемых в задаче.
S - множество исходов (конечных результатов), то есть результатов взаимодействия управляемых и неуправляемых факторов в системе.
D - множество операторов d, переводящих систему из YxZ на S. Содержательно d характеризует сам акт взаимодействия управляемых и неуправляемых факторов, процесс преобразования. В рамках теории управления D разбивается на два подмножества: D1 –управляемые операторы; D2 – неуправляемые операторы.
W – цель выбора подмножества So по критерию U.
U – множество критериев оценки элементов множества S и выбора So.
Традиционная схема процесса выбора (принятия решения) |
||
|
Интересы, потребности, |
|
|
мотивы, запросы, |
|
Субъект |
ценности, предпочтения |
|
выбора |
|
|
|
Оценка |
Результат |
|
и сравнение |
выбора |
Альтернативы |
Информация об альтернативах, |
|
|
|
|
|
представления, декларативные |
|
|
модели |
|
Традиционная схема процесса выбора с учетом процесса выбора |
|||
|
|
предпочтений |
|
|
Предпочтения о |
Информация о цели |
|
|
выбора, о действиях |
||
|
предпочтениях |
||
|
|
|
|
Субъект |
|
|
|
выбора |
|
|
|
|
|
Выбор |
|
|
предпочтений |
|
|
Альтернативные |
|
Оценка |
Результат |
|
и сравнение |
выбора |
|
предпочтения |
|
||
|
|
|
|
Альтернативы |
Информация об альтернативах, |
|
|
|
|
|
|
|
|
представления, декларативные |
|
|
|
модели |
|
Суть традиционной схемы:
1.В ней вся внешняя обстановка ситуации выбора моделируется через альтернативы выбора.
2.Вся необходимая для осуществления выбора информация о субъекте (о его свойствах, параметрах его индивидуальности, его текущем состоянии и т.д.) агрегируется в его предпочтениях.
3.Суть процесса выбора (принятия решения) – оценить имеющиеся альтернативы в свете актуализированных предпочтений и сравнить эти оценки между собой.
НО
Схема имеет внутренние противоречия, которые становятся явными при попытке уточнить процесс выбора (т.е. принятия решения в традиционной схеме) предпочтений.
Вопрос:
Как происходит отбор предпочтений для конкретной ситуации
выбора?
Логика процесса выбора ЛПР
Представления об альтернативах Декларативное знание
ЛПР отрабатывает для ситуации свои схемы, которые у него закрепляются в стереотипах мышления и поведения
Субъект
выбора
Представления о действиях Процедуральное знание
Представления о
Результат ценностях выбора
Процесс выбора, осуществляемый ЛПР состоит в одновременном конструировании им для данной ситуации выбора 3-х исходных объектов и одного результирующего
Методы исследования пользователей
1.Анализ требований
2.Стратегии выявления требований
3.Маркетинговые исследования
4.Исследование контекста
5.Метод карточной сортировки
6.Анализ рабочих заданий
7.Сегментация пользовательской аудитории (метод персонажей)
Функциональные, нефункциональные требования
Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements).
Функциональные требования отвечают на вопрос "что должна делать система" в тех или иных ситуациях. Функциональные требования определяют основной "фронт работ" Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
Функциональные требования записываются разными способами. Например при посредстве предписывающих правил: "система должна позволять …… ", при помощи задания вариантов использования (users cases) и т.д. Это - основной, определяющий вид требований.
Нефункциональные требования регламентируют внутренние и внешние условия или атрибуты функционирования системы. Выделяют следующие основные группы нефункциональных требований:
1.Внешние интерфейсы (External Interfaces).
–интерфейс пользователя (User Interface, UI)
–интерфейсы с внешними устройствами (аппаратные интерфейсы);
–программные интерфейсы;
–интерфейсы передачи информации (коммуникационные интерфейсы).
2.Атрибуты качества (Quality Attributes),
3.Ограничения (Constraints).
Основные атрибуты качества:
–применимость,
–надежность,
–производительность,
–эксплуатационная пригодность и т.д.
Источники требований
1.Основным источником требований к информационной системе являются соображения, высказанные представителями Заказчика. Данная информация структурируется как минимум на 2 уровня:
–бизнес-требования;
–требования пользователей.
Проблема состоит в том, что требования формулируются к создаваемой, еще не существующей системе, т.е. по сути решается начальная подзадача задачи проектирования АИС, а представители Заказчика далеко не всегда бывают компетентны в данном вопросе
2.Наряду с требованиями, высказанными Заказчиком, целесообразно собирать и требования от других совладельцев системы:
–сотрудников аналитической группы исполнителя;
–внешних экспертов и т.д.
Результирующий, часто достаточно сырой материал представляется, как документ «Требования совладельцев (стейкхолдеров)». На требования совладельцев обычно не накладывается никаких специальных ограничений.