Как проводить анализ предметной области

11. Анализ предметной области: цели и задачи. Модели предметной области. Формальные определения. Классификация моделей. Методоло

11. Анализ предметной области: цели и задачи. Модели предметной области. Формальные определения. Классификация моделей. Методология IDEF0, синтаксис IDEF0-моделей.

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

1. · понимать язык, на котором говорят заказчики;
2. · выявить цели их деятельности;
3. · определить набор решаемых ими задач;
4. · определить набор сущностей, с которыми приходится иметь дело при решении этих задач.

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

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

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

Формальные модели, используемые на этапе анализа предметной области можно разделить на две группы:

1. · модели, зависящие от подхода к разработке (структурного или объектно-ориентированного);
2. · модели, не зависящие от подхода к разработке.

В рамках проекта ICAM планировалась разработка семейства методологий моделирования различных аспектов функционирования систем:

1. IDEF0 – методология создания функциональной модели системы (основана на методе SADT Росса);
2. IDEF1 – методология создания информационной модели системы (основана на реляционной теории Кодда и использовании ER-диаграмм Чена);
3. IDEF2 – методология создания динамической модели системы;
4. IDEF3 – методология создания модели потоков работ (обычно используется вместе с диаграммами потоков данных DFD Data flow diagram)

Основной формой представления IDEF0-модели является диаграмма. Каждая IDEF0-диаграмма содержит блоки (работы) и дуги (стрелки). Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.
Функциональные блоки на диаграмме изображаются прямоугольниками, а дуги – стрелками.

Каждая сторона функционального блока должна иметь стандартное отношение блок/стрелки:

1. · входные стрелки должны связываться с левой стороной блока;
2. · управляющие стрелки должны связываться с верхней стороной блока;
3. · выходные стрелки должны связываться с правой стороной блока;
4. · стрелки механизма (кроме стрелок вызова) должны указывать вверх и подключаться к нижней стороне блока;
5. · стрелки вызова механизма должны указывать вниз, подключаться к нижней стороне блока, и помечаться ссылкой на вызываемый блок

В метках стрелок использоваться следующие термины:

Сегменты стрелок, за исключением стрелок вызова, должны помечаться существительным или оборотом существительного. Чтобы связать стрелку с меткой, следует использовать «тильду» (

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

Состав

IDEF0-модели состоят из трех типов документов:

1. · графических диаграмм(главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения)
2. · текста(используется для объяснений и уточнений характеристик, потоков, внутриблочных соединений и т.д.)
3. · глоссария (предназначен для определения аббревиатур, ключевых слов и фраз, используемых в качестве имен и меток на диаграммах)

Эти документы имеют перекрестные ссылки друг на друга. В методологии IDEF0 существует 6 типов отношений между блоками в пределах одной диаграммы:

1. · доминирование;
2. · управление;
3. · выход — вход;
4. · обратная связь по управлению;
5. · обратная связь по входу;
6. · выход – механизм

источник

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

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

Один из современных подходов к разработке информационных систем основывается на выделении документарных элементов в бизнес-процессе, где атрибутами являются сущности (объекты) предметной области, впоследствии представляемые сущностями логической модели базы данных. Этот подход может быть применим только на уровне контекстного рассмотрения бизнес-процессов и проведения операций декомпозиции бизнес-процессов, по, при переходе па уровень моделирования потоков данных смысл использования документарного подхода теряется, поскольку сама суть моделей потоков данных предполагает работу с объектами данных, некоторые из которых могут представляться в предметной области виртуальными представлениями и не существовать в документах, а также по причине отсутствия необходимости, кроме отдельных частных случаев, хранения информации о документах, которые сами по себе не являются объектами предметной области [1] [2] .

Учитывая эту особенность подхода к разработке информационных систем, и в частности баз данных, разработчиками в качестве бизнес-элемента рассматриваются элементы, информационно описывающие производимый продукт/услугу и вспомогательные объекты, которые в частных случаях могут представляться документами и информационными объектами, где атрибутами являются характеризующие их другие объекты предметной области, а также характеристические атрибуты соответствующих объектов. Это, по сути, означает, что информационный объект предметной области может представляться документом, содержать в своей структуре указание на другие объекты и дополняться собственными характеристиками (атрибутами) простых типов (рис. 2.2).

Рис. 2.2. Объектно-атрибутивное представление предметной области

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

Такое представление модели базы данных является идеальным, подразумевая реализацию линейных цепочек взаимосвязей объектов предметной области, и представляется в форме звезды или снежинки (рис. 2.3).

Рис. 23. Общее представление идеальной объектной модели данных

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

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

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

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

источник

Вопрос №1.Что определяют требования к ПО? Для чего нужен анализ предметной области?

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

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

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

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

выявление свойств желаемых результатов

определение набора задач, для их достижения

определение набора сущностей, необходимых при решении этих задач

определение области ответственности будущей программной системы

После этого можно уже более точно сформулировать требования к ПО.

Ответ: Бизнес моделирование — это анализ такой предметной области, связанной с коммерческой организацией. Соответственно, между этими двумя процессами имеется бинарное отношение обобщения. Бизнес моделирование наследует анализ предметной области.

Всякий ненужный текст, предназначенный для увеличения объёма:

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

Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы. Разработчики должны научиться

· понимать язык, на котором говорят заказчики;

· выявить цели их деятельности;

· определить набор решаемых ими задач;

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

Схема Захмана (или архитектурная схема предприятия) основана на дисциплине классической архитектуры и применяется для систематизации сбора информации о больших организациях и дальнейшей разработки систем, поддерживающих их деятельность.

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

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

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

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

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

Расшифровка строк таблицы:

Planner’s View ( Contextual level) — общее, высокоуровневое видение архитектуры решения с точки зрения инвестора или заказчика. Owner’s View (Enterprise or Business Model, Conceptual level) — уровень бизнеса, бизнес-сущностей и бизнес-процессов, то есть взгляд с точки зрения пользователей данного решения. Designer’s View (Information Systems Model, Logical level) — представление системного аналитика о решении на уровне информационных моделей, функциональных требований к решению и потоков данных. Builder’s View (Technology Model, Physical level) — представление архитектора, нацеленное на использование конкретных технологий, языков программирования, устройств и платформ. Subcontractor View (Detailed level) — уровень детализированного представления о внутреннем устройстве всех компонентов решения, нацеленный на разработчиков и программистов.

Дать понятие заинтересованных в разработке ПО лиц.

Цель программного проекта, как и любого другого — удовлетворение заинтересованных лиц. Между тем, работе с ними обычно уделяется недостаточное внимание. Люди концентрируются на различных артефактах, и не всегда упоминают, что любые артефакты — лишь средство удовлетворения заинтересованных лиц. Это справедливо даже в том случае, когда что-то создаётся «just for fun»: автор артефакта — такое же заинтересованное лицо, как и все остальные.

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

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

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

Так как количество видов ПО и практик велико, первоначальный автор рассчитывает на активное участие сообщества в написании данной статьи.

* Инвестор — интересы в скорейшем возврате инвестированных денег с одной стороны, и постоянном доходе в будущем — с другой

* Команда 1 — в зависимости от личностей и командных традиций, интересы в скорейшей разработке «на результат», как можно более долгой разработке «потому что нравится процесс» или чтобы сохранить работу, как можно более качественных артефактах «чтобы потом было легко поддерживать» или чтобы «забыть как страшный сон», или не слишком качественных артефактах, чтобы поддерживая их, сохранять работу; баланс существующих и новых технологий; баланс повторного использования и разработки заново

* Продавцы — как можно большие объёмы продаж сейчас с одной стороны, и высокие объёмы продаж в течение длительного времени — с другой (востребованность, наличие ярких продающих факторов, качество при длительной работе)

* Инженеры пресейла — возможность как можно легче продемонстрировать возможности и привлекательность продукта кастомизаторам и интеграторам

* Команда 1 — аналогично команде разработчиков, кроме того — наличие у продукта средств разработки и отладки, руководства разработчика, простота и комментированность предназначенного для кастомизации кода, большое количество заготовок для повторного использования (в т.ч. с учётом отраслевой специфики)

* Компания, оказывающая тех. поддержку

Классификация практик разработки ПО и работа с заинтересованными лицами в их рамках

* Процессы, подразумевающие высокое доверие и вовлечение Заказчика

* Процессы, подразумевающие низкое доверие и вовлечение Заказчика

* По степени изменчивости требований и обязательств их учёта

* Прямое управление приоритетами компании-разработчика

источник

Лекция 1. Этапы проектирования БД

ТЕМА 1.3. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

1. Что такое реляционная база данных?

2. Что такое запись и поле?

3. Что такое первичный ключ?

6. Расскажите о видах связей между таблицами?

7. В чём суть ссылочной целостности?

8. Перечислите и охарактеризуйте основные операции реляционной алгебры?

9. Где используются операции реляционной алгебры?

Процесс конструирования базы данных (ее проектирования и реализации) состоит из последовательности преобразований модели данных одного уровня в модель данных другого уровня.

— систематизация объектов реального мира;

— создание информационных структур, описывающих систему объектов реального мира;

— создание структуры данных, которая используется для представления информационных структур в базе данных и прикладных программах;

— представление структуры памяти, используемой для хранения структур данных.

Первый этап — анализ предметной области или этап концептуального проекти­рования. На этапе концептуального проектирования осуществляется сбор, анализ и редактирование требований к данным.

Первым этапом проектирования БД любого типа является анализ предметной об­ласти, который заканчивается построением информационной структуры (концепту­альной схемы). На данном этапе анализируются запросы пользователей, выбираются информационные объекты и их характеристики, которые предопределяют содержа­ние проектируемой БД. На основе проведенного анализа структурируется предметная область. Анализ предметной области не зависит от программной и технической сред, в которых будет реализовываться БД.

1) анализ требований и информационных потребностей;

2) выявление информационных объектов и связей между ними;

3) построение модели предметной области и проектирование схемы БД.

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

1) анализ требований пользователей к базе данных (концептуальных требований);

2) выявление имеющихся задач по обработке информации, которая должна быть представлена в базе данных (анализ приложений),

3) выявление перспективных задач (перспективных приложений);

4) документирование результатов анализа

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

Рассмотрим примерный состав вопросника, требований к базе данных при анализе различных предметных областей.

Пример 1. Пусть предлагается разработать систему вопросов к БД «Сессия студентов колледжа»:

1. Сколько студентов учится в колледже?

2. Сколько отделений в данном колледже?

3. Как распределены студенты по отделениям отделений и курсам?

4. Сколько дисциплин читается на каждом курсе по каждой специальности?

5. Как часто обновляется информация в базе данных?

7. Сколько иногородних студентов живет в общежитии, на частных квартирах?

8. Какая преемственность существует между читаемыми курсами?

9. Сколько лекционных аудиторий и аудиторий для проведения практических за­нятий, лабораторий?

10. Как информация, представленная в п.п. 1-9, используется в настоящее время (расписание занятий, экзаменов, зачетов и т.д.) и как ее собираются использовать?

11. Сколько раз в день, сколько человек и кто пользуются БД?

Пример 1 (продолжение). Выполним анализ требований к БД «Сессия студентов». Вопрос 1. Для каких типов задач (приложений) проектируется БД? Ответ. Для трех типов задач: Задача 1. Информация о студентах. Задача 2. Инфор­мация о преподавателях. Задача 3. Информация об успеваемости студентов. Задача 4. Информация о предметах.

Вопрос 2. Какими информационными объектами характеризуются эти задачи? Ответ. Задача 1 характеризуется информационным объектом: личные дела студен­тов. Задача 2 характеризуется информационным объектом: личные дела преподава­телей. Задача 3 характеризуется одним информационным объектом — сессия. Задача 4 характеризуется одним информационным объектом — предметы.

Вопрос 3. Каким текущим запросам должны удовлетворять данные информационные объекты?

Вопрос 4. Каким перспективным запросам должны удовлетворять информационные объекты в БД «Сессия студентов»?

Пример 2. Пусть требуется разработать требования к локальной БД «Аэропорт».

Вопрос 1. Для каких типов задач (приложений) проектируется БД? Ответ. Для трех типов задач: Задача 1. Информацияоб обслуживающем персонале. Задача 2. Информация о полетных средствах Задача 3. Информация о графике дви­жения самолетов.

Вопрос 2. Какими информационными объектами характеризуются эти задачи? Ответ. Задача 1 характеризуется тремя информационными объектами: летный со­став, диспетчеры, технический персонал. Задача 2 характеризуется двумя информа­ционными объектами: самолет, взлетное поле. Задача 3 характеризуется одним ин­формационным объектом — рейсы.

Вопрос 3. Каким текущим запросам должны удовлетворять данные информационные объекты? Ответ.

1. ФИО, звание, должность членов экипажа самолета.

2. Списочный состав диспетчеров.

3. Состав смены технического персонала.

4. Тип самолета, который может обслуживать тот или иной пилот.

5. Номер самолета, который обслуживает данный пилот, данная смена диспетчеров и технического персонала.

6. Номер личного дела сотрудника аэропорта.

7. Номер смены диспетчеров и технического персонала, обслуживающего аэропорт в заданном интервале времени.

8. Готовность самолета с номером № к полету.

9. Количество часов налета самолета с № .

10. Готовность данной взлетной полосы в настоящее время.

12. Номер (номера) рейса до данного пункта назначения.

13. Какие промежуточные посадки совершает рейс № ?

14. Время вылета и расчетное время прибытия рейса № .

15. Время и место регистрации рейса №

17. До какого времени задерживается рейс № ?

18. Какие типы самолетов обслуживают рейс №. ?

19. Какой номер самолета обслуживает рейс N°. ?

Вопрос 4. Каким перспективным запросам должны удовлетворять информационные объекты в БД «Аэропорт»?

1. С какого года используется самолет с № в аэропорту, тип самолета?

2. Какое количество часов полета у члена экипажа, ФИО?

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

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

При выборе информационных объектов следует ответить на следующие вопросы:

1. На какие классы можно разбить данные, подлежащие хранению в БД?

2. Какое имя можно присвоить каждому классу данных?

3. Какие наиболее интересные характеристики (с точки зрения пользователя) каж­дого класса данных можно выделить?

4. Какие имена можно присвоить выбранным наборам характеристик?

В ходе выявления связей между информационными объектами следует ответить на следующие вопросы:

1. Какие типы связей между информационными объектами?

2. Какое имя можно присвоить каждому типу связей?

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

4. Имеют ли смысл какие-нибудь комбинации типов связей?

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

При выявлении условий ограничения целостности проектировщик пытается отве­тить на следующие вопросы:

1. Какова область значений для числовых характеристик?

2. Каковы функциональные зависимости между характеристиками одного инфор­мационного объекта?

3. Какой тип отображения соответствует каждому типу связей?

Пример 1 (продолжение). Для БД «Сессия студентов» выберем следующие сущности: институт, факультет, студент, преподаватель, дисциплина, ведомость. Каждую сущность зададим набором атрибутов (ключевые атрибуты подчеркнем): институт (сокращение , название, подчиненность, адрес, телефон, ФИО ректора).

факультет (код Факультета , название, код специальности, декан). кафедры факультета (код кафедры , название, код факультета, зав.кафедрой). студент (номер зачетной книжки , ФИО, группа, пол, дата рождения, домашний ад­рес, телефон).

дисциплина (шифр дисциплины , название, число часов, виды занятий, число читае­мых семестров, на каких курсах преподается).

ведомость (№ п/п, номер зачетной книжки студента, код дисциплины, семестр, фор­ма сдачи, дата сдачи, отметка, преподаватель). Определим связи между сущностями.

Рассмотрим некоторые ограничения на характеристики объектов:

1. Значение атрибута «телефон» (сущность — институт) задается целым положи­
тельным шестизначным числом, задавать значение будем по маске __-__-__ .

2. Значение атрибута «код факультета» (сущность факультет) лежит в интервале
0-10.

3. Значение атрибута «курс» (сущность — студент) лежит в интервале 1-6 и хранится первая цифра номера группы.

4. Значение атрибута «семестр» (сущность — студент, дисциплина) лежит в интерва­ле 1-12.

5. Значение атрибута «число часов» (сущность — дисциплина) лежит в интервале 1-300.

6. Одному студенту может быть приписана только одна группа.

7. Один студент может учиться только на одном факультете.

8. Один студент в семестре сдает от 3 до 10 дисциплин.

9. Один студент изучает в семестре от 6 до 12 дисциплин.

10.Одному преподавателю приписывается только одна кафедра.

11.Один студент может пересдавать одну дисциплину не более трех раз.

Ключи: сокращение (названия института), код факультета, номер зачетной книжки, № страхового свидетельства преподавателя, шифр дисциплины, № п/п.

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

Концептуальная модель включает описания объектов и их взаимосвязей, пред­ставляющих интерес в, рассматриваемой предметной области (ПО) и выявляемых в результате анализа данных. Концептуальная модель применяется для структурирова­ния предметной области с учетом информационных интересов пользователей систе­мы. Она дает возможность систематизировать информационное содержание предмет­ной области, позволяет как бы «подняться вверх» над ПО и увидеть ее отдельные элементы.

При этом, уровень детализации зависит от выбранной модели. Концепту­альная модель является представлением точки зрения пользователя на предметную область и не зависит ни от программного обеспечения СУБД, ни от технических ре­шений. Концептуальная модель должна быть стабильной. Могут меняться приклад­ные программы, обрабатывающие данные, может меняться организация их физиче­ского хранения, концептуальная модель остается неизменной или увеличивается с целью включения дополнительных данных.

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

Под сущностью понимают основное содержание объекта ПО, о котором собирают информацию. В качестве сущности могут выступать место, вещь, личность, явление. Экземпляр сущности — конкретный объект. Например: сущность (объект) — студент, экземпляр сущности — Иванов А. В.; сущность (объект) — институт, экземпляр сущно­сти — КГУ.

Сущность принято определять атрибутами — поименованными характеристика­ми. Например: сущность — студент, атрибуты — ФИО, год рождения, адрес, номер группы ит.д.

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

Не нашли то, что искали? Воспользуйтесь поиском:

источник

Практическая работа №1

Системный анализ предметной области

Цель работы: получить представление о системном анализе предметной области.

Теоретическая часть

Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.

В общем случае можно выделить следующие этапы проектирования:

1. Системный анализ и словесное описание информационных объектов предметной области.
2. Проектирование инфологической модели предметной области — частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели.
3. Даталогичеcкое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных.
4. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

Если учитывать, что между вторым и третьим этапами необходимо принять решение, с использованием какой стандартной СУБД будет реализовываться наш проект, то условно процесс проектирования БД можно представить последовательностью выполнения пяти соответствующих этапов. Рассмотрим более подробно этапы проектирования БД.

Рисунок 1 — Этапы проектирования БД

Системный анализ предметной области

С точки зрения проектирования БД в рамках системного анализа, необходимо осуществить первый этап, то есть провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области.

В общем случае существуют два подхода к выбору состава и структуры предметной области:

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

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

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

Пример описания предметной области

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

• уникальный шифр;
• название;
• фамилии авторов (могут отсутствовать);
• место издания (город);
• издательство;
• год издания;
• количество страниц;
• стоимость книги;
• количество экземпляров книги в библиотеке.

Книги могут иметь одинаковые названия, но они различаются по своему уникальному шифру (ISBN).

В библиотеке ведется картотека читателей.

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

• фамилия, имя, отчество;
• домашний адрес;
• телефон (будем считать, что у нас два телефона — рабочий и домашний);
• дата рождения.

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

Каждый читатель может одновременно держать на руках не более 5 книг. Читатель не должен одновременно держать более одного экземпляра книги одного названия.

Каждая книга в библиотеке может присутствовать в нескольких экземплярах. Каждый экземпляр имеет следующие характеристики:

• уникальный инвентарный номер;
• шифр книги, который совпадает с уникальным шифром из описания книг;
• место размещения в библиотеке.

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

• номер билета читателя, который взял книгу;
• дата выдачи книги;
• дата возврата.

Предусмотреть следующие ограничения на информацию в системе:

1. Книга может не иметь ни одного автора.
2. В библиотеке должны быть записаны читатели не моложе 17 лет.
3. В библиотеке присутствуют книги, изданные начиная с 1960 по текущий год.
4. Каждый читатель может держать на руках не более 5 книг.
5. Каждый читатель при регистрации в библиотеке должен дать телефон для связи: он может быть рабочим или домашним.
6. Каждая область знаний может содержать ссылки на множество книг, но каждая книга может относиться к различным областям знаний.

С данной информационной системой должны работать следующие группы пользователей:

• библиотекари;
• читатели;
• администрация библиотеки.

При работе с системой библиотекарь должен иметь возможность решать следующие задачи:

1. Принимать новые книги и регистрировать их в библиотеке.
2. Относить книги к одной или к нескольким областям знаний.
3. Проводить каталогизацию книг, то есть назначение новых инвентарных номеров вновь принятым книгам, и, помещая их на полки библиотеки, запоминать место размещения каждого экземпляра.
4. Проводить дополнительную каталогизацию, если поступило несколько экземпляров книги, которая уже есть в библиотеке, при этом информация о книге в предметный каталог не вносится, а каждому новому экземпляру присваивается новый инвентарный номер и для него определяется место на полке библиотеки.
5. Проводить списание старых и не пользующихся спросом книг. Списывать можно только книги, ни один экземпляр которых не находится у читателей. Списание проводится по специальному акту списания, который утверждается администрацией библиотеки.
6. Вести учет выданных книг читателям, при этом предполагается два режима работы: выдача книг читателю и прием от него возвращаемых им книг обратно в библиотеку. При выдаче книг фиксируется, когда и какой экземпляр книги был выдан данному читателю и к какому сроку читатель должен вернуть этот экземпляр книги. При выдаче книг наличие свободного экземпляра и его конкретный номер могут определяться по заданному уникальному шифру книги или инвентарный номер может быть известен заранее. Не требуется вести «историю» чтения книг, то есть требуется отражать только текущее состояние библиотеки. При приеме книги, возвращаемой читателем, проверяется соответствие возвращаемого инвентарного номера книги выданному инвентарному номеру, и она ставится на свое старое место на полку библиотеки.
7. Проводить списание утерянных читателем книг по специальному акту списания или замены, подписанному администрацией библиотеки.
8. Проводить закрытие абонемента читателя, то есть уничтожение данных о нем, если читатель хочет выписаться из библиотеки и не является ее должником, то есть за ним не числится ни одной библиотечной книги.

Читатель должен иметь возможность решать следующие задачи:

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

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

Этот совсем небольшой пример показывает, что перед началом разработки необходимо иметь точное представление о том, что же должно выполняться в системе, какие пользователи в ней будут работать, какие задачи будет решать каждый пользователь. И это правильно, ведь когда строят здание, тоже заранее предполагается: для каких целей оно предназначено, в каком климате оно будет стоять, на какой почве, и в зависимости от этого проектировщики могут предложить нам тот или иной проект. Но, к сожалению, очень часто по отношению к базам данных считается, что все можно определить потом, когда проект системы уже создан. Отсутствие четких целей создания БД может свести на нет все усилия разработчиков, и проект БД получится «плохим», неудобным, не соответствующим ни реально моделируемому объекту, ни задачам, которые должны решаться с использованием данной БД.

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

источник

Как отмечалось ранее, базы данных сами по себе представляют относительную ценность. Базы данных — это всегда важнейшая, но только одна из составляющих некоторой информационной системы (ИС). И надо отметить, что любая информационная система, предназначенная, например, для оперативного управления предприятием или архивного хранения и поиска документов — это не только программы, данные и коммуникации, но и люди (заказчики, пользователи, аналитики, разработчики), организационные структуры, а также цели, стимулы работы предприятия или отдельных людей. И все эти компоненты должны быть понятным как проектировщику, так и пользователю, а кроме того, непротиворечивым образом соединены в одну систему.

Главная идея процесса такого согласования состоит в том, что его надо начинать с анализа самых главных характеристик предметной области, рассматривая самые главные содержательные аспекты. И проводить его не «мысленно» и не «на словах», а на явно изложенных описаниях (моделях) объектов предметной области, позволяющих видеть все существенные взаимосвязи. Однако следует отметить, что попытки использования привычных нотаций формальных моделей (структурных, объектных или каких-либо других) на этом этапе приводят к более низкому (более детальному, и в то же время ограниченному) уровню представления предметной области, чем это необходимо для общего понимания.

В общем случае существуют два подхода к определению состава и структуры предметной области.

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

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

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

В [29] была предложена простая, но концептуально мощная схема, показывающая различные уровни представления архитектуры ИС, различные виды ее «обеспечения», а также их основные взаимосвязи. На рис. 5.2 показана таблица, представленная в [7], аналогичная схеме Захмана. Три столбца обозначают три раздела обеспечения системы: информационный (ДАННЫЕ), функциональный (ФУНКЦИИ) и коммуникационный (СЕТЬ).

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

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

Позднее появилось развитие такой «плоской» модели. В [28] рассматривалась схема, представленная на рис. 5.3, включающая три новых столбца, в которых отражаются еще три раздела: побудительные причины действий системы, события и графики выполнения действий, а также «действующие лица» — люди и организационные структуры.

В результате появилось шесть разделов, которые содержат «ответы на вопросы: почему выполняются действия, когда выполняются

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

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

Цель системного анализа предметной области как этапа проектирования — выделить предметную область как систему объектов и их взаимосвязей, определив при этом функционально-информационные требования к их последующему представлению в виде системы взаимосвязанных данных.

Главным результатом этапа системного анализа является определение парадигмы информационной (инфологической) модели:требования к средствам представления системы определяются на основании анализа уровня структурированности информации и характера восприятия ее семантики пользователем (точная или приблизительная, четкая или неопределенная).

Например, выбор атрибутивной формы представления объектов предметной области приведет, соответственно, к выбору парадигмы фактографических баз данных, а вербальной — к необходимости выбора документальных БД.

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

Дата добавления: 2015-04-15 ; просмотров: 2672 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

источник

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

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

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

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

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

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

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

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

Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта.

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

1. Отвечает ли система бизнес-целям организации-заказчика и организации-разработчика?
2. Можно ли реализовать систему, используя известные технологии и не выходя за пределы заданной стоимости и заданного времени?
3. Можно ли объединить систему с другими уже эксплуатируемыми системами?

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

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

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

Постановку бизнес-задачи надо обсуждать с Заказчиком, или будущим Владельцем системы.

Вопросы, которые ему стоит задать, это:

1. Почему вообще пошла речь о создании системы?
2. В чём Вы видите её назначение?
3. Какие бизнес-возможности она должна реализовать?
4. Какие проблемы должна решить?

В качестве «Стандарта» на вопросы такого рода смотрите шаблон документа » Stakeholder Request», например, из RUP . Бизнес-требования может выразить Заказчик или Эксперты предметной области . Они обычно фиксируются в виде списка из 10-30 ключевых свойств продукта — в качестве шаблона см. Vision из RUP .

Бизнес-моделирование надо проводить на основе информации от, а лучше совместно с экспертами предметной области . Вопросы по сути сводятся к «Что, почему, когда, как и кем происходит в предметной области и как оно взаимосвязано?»:

1. Каковы основные понятия предметной области, их определения и взаимосвязи? Результат можно оформить в виде глоссария и/или концептуально-семантической модели предметной области.
2. На основании каких правил — международных, федеральных, муниципальных, районных и т.д. законов, указов, стандартов, спецификаций, регламентов и т.д. — происходит то, что происходит в предметной области? Результат оформляете в виде структурированного списка или прикрепляете к элементам концептуальной модели.
3. Что реально (какие процессы, события, факты) происходит и в какой последовательности, взаимосвязи? Результат оформляете в виде сценариев описания бизнес-процессов (что достаточно универсально) или диаграмм SADT ( IDEF0 , >DFD ) / ARIS (eEPC и т.д.) / UML (Business Use-case Diagram (BUC) + Activity Diagram + Sequence Diagram ). Это один из сложнейших этапов.
4. Какими свойствами обладает каждое из выделенных понятий — структурными и поведенческими? Результат описывается в виде таблиц с атрибутами Концептуальных сущностей или Детальной концептуальной моделью — ER — IDEF1X / UML Class Diagram ( BOM ).

Существует российский стандарт функционального моделирования P 50.1.028-2001, созданный на основе IDEF0 .

Определение требований — частично Бизнес-требования и Требования, проистекающие из предметной области вы уже определили выше, теперь осталось исследовать Пользовательские требования и Системные требования и ограничения к отдельным аспектам качества системы. Пользовательские требования , как можно понять, нужно выявлять из общения с потенциальными пользователями системы. Вопросы:

1. На какую систему будет похожа создаваемая?
2. С какими системами и как давно вы работаете?
3. Какое у вас образование?
4. Каковы ваши ожидания от системы — что и как она должна делать, какие задачи помогать решать, как должна выглядеть?
5. Какие шаги необходимо предпринять для решения каждой задачи?
6. В каком случае вы будете считать, что система «Хороша»?

Результаты анкетирования/интервьюирования обычно представляют в виде пользовательских историй ( User Story , Agile) или Пользовательских сценариев (Use-case), также возможно их диаграммное представление средствами диаграмм потока работ ( >ARIS , Activity/State UML Diagram . Подробнее про работу с Пользователями могут рассказать специалисты по Проектированию взаимодействия, интерфейсам и эргономике.

Системные требования нужно выяснять у IT-специалистов Заказчика, если таковые имеются, из специфики контекста использования системы, опыта построения аналогичных систем (у IT-Экспертов-Архитекторов) и Специалистов по отдельным аспектам системы, значимым для данного проекта (Юристы, Эргономисты, и т.д.) и Заказчика:

1. Будет ли система единичной или тиражируемой?
2. В каких странах она будет работать?
3. Насколько важна информация, хранящаяся, обрабатываемая и передающаяся системой?
4. Каков возможный ущерб от потери той или иной информации?
5. Сколько пользователей будет работать с системой сегодня, завтра, через год?

Переработанный результат оформляется в виде Системных требований ( Software Requirement Specification , стандарт IEEE-STD-830-1998, или ТЗ ГОСТ 34-602-89 или неформально в виде Supplementary Specificaion из RUP ).

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

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

Оптимальный подбор предоставляемых средств определяет все остальное

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

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

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

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

1. требования проекта и целевое назначение завершенного продукта;
2. философия проекта;
3. архитектура приложения;
4. текущее состояние работ в данном направлении;
5. план, в соответствии с которым продукт будет переводиться из его текущего состояния в состояние успешного завершения.

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

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

источник