Анализ предметной области для создания своего предприятия

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

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

Анализ предметной области можно разбить на три фазы:

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

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

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

На этапе анализа концептуальных требований и информационных потребностей необходимо выполнить:

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

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

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

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

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

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

1. Какая документация и какого типа существует на данной кафедре?

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

3. Сбор шаблонов, необходимых для создания документов.

4. Какие объекты кроме документов должно храниться в базе, и какими свойствами должны обладать данные объекты?

5. По каким критериям должен проводиться поиск по базе?

6. Для кого предназначена БД?

Выполним анализ требований к БД.

Вопрос1. Для каких типов задач проектируется БД?

Ответ. 1. Информация о документах. 2. Информация о преподавателях. 3. Информация о студентах, участвующих в работе кафедры. 4.Информация о кафедрах, на которых преподаватели данной кафедры работают совместителями. 5. Информация об олимпиадах, проводимых преподавателями данной кафедры. 6. Информация о конференциях по данной кафедре. 7. Учет участия студентов в олимпиадах. 8. Учет участия студентов в конференциях. 9. Информация о возможных должностях преподавателей. 10. Информация о возможных ученых степенях преподавателей. 11. Информация о возможных ученых званиях преподавателей. 12. Информация о литературе, имеющейся на кафедре. 13. Информация об авторах. 14. Информация об издательствах. 15. Информация о научных работах преподавателей. 16. Информация о дисциплинах, преподаваемых в рамках кафедры. 17. Информация о рабочих программах по дисциплинам. 18. Информация о типе документации (приказ, заявление и т.п.). 19. Информация о типе литературы (пособие, учебник и т.п.). 20. Учет преподавателей по кафедрам. 21. Информация о курсовых работах. 22. Учет студентов по курсовым работам. 23. Информация о специальностях данного ВУЗа. 24. Информация о типе научных работ преподавателей.

Вопрос2. Какими информационными объектами характеризуются эти задачи?

Ответ. 1. Информационный объект: Документация. 2. Информационный объект: Преподаватели. 3. Информационный объект: Студенты. 4. Информационный объект: Кафедры. 5. Информационный объект: Олимпиады. 6. Информационный объект Конференции. 7. Информационный объект Учет олимпиад. 8.Информацинный объект Учет конференций. 9. Информационный объект Должности. 10. Информационный объект Тип ученых степеней. 11. Информационный объект Тип ученых званий. 12. Информационный объект Литература. 13. Информационный объект Авторы. 14. Информационный объект Издательства. 15. Информационный объект Научные работы преподавателей. 16. Информационный объект Дисциплины. 17. Информационный объект Рабочие программы. 18. Информационный объект Тип документации. 19. Информационный объект Тип литературы. 20. Информационный объект Учет преподавателей по кафедрам. 21. Информационный объект Курсовые работы. 22. Информационный объект Учет студентов по курсовым работам. 23. Информационный объект Специальности. 24. Информационный объект Тип научных работ преподавателей.

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

1. Название олимпиады, курсовой работы, конференции, рабочей программы, тип документации, типа литературы, типа научной работы и т.п..

2. ФИО преподавателя, автора, студента.

3. Ученое звание, ученая степень преподавателя.

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

5. Адрес преподавателя, издательства.

6. Телефон преподавателя.

7. Номер группы студента.

8. Направление научной работы преподавателя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждую сущность в нашей БД зададим набором атрибутов (ключевые атрибуты подчеркнем):

1.Документация(код документации, название, тип, дата создания, текст);

2. авторы(код автора, Фамилия, Имя, Отчество);

3. дисциплины(код дисциплины, название);

4. кафедры(код кафедры, название);

5. должность(код, название);

6. издательства(код, название, город, улица, офис);

7. конференции(код, название, дата проведения, код литературы);

8. курсовая работа(код, название, код дисциплины, номер зачетки, код руководителя, дата защиты, оценка, текст, приложение);

9. литература (код, название, код автора, код издания, код типа, дата создания);

10. направление (код, название);

11. научные работы преподавателей(код, название, тип научной работы, код преподавателя, дата создания, направление, текст);

12. олимпиада(код, название, код дисциплины, дата проведения);

13. преподаватели(Инн преподавателя, фамилия, имя, отчество, телефон, адрес, код договора, дата рождения, код ученой степени, код ученого звания);

14. рабочие программы (код, название, код специальности, код дисциплины, дата создания, код составителя, текст);

15. специальности(код, название);

16.студенты (номер зачетки, Фамилия, Имя, Отчество, номер группы);

17. тип документации(код, название);

18. тип литературы(код, название);

19. тип научной работы(код, название);

20. тип ученого звания (код, название);

21.тип ученой степени (код, название);

22. учет конференций (код, номер зачетки, код конференции, тема доклада);

23. учет олимпиад(код, номер зачетки, код олимпиады, результат);

24.учет преподавателей по кафедрам (код, инн преподавателя, код кафедры, код должности).

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

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

Одной из распространенных моделей концептуальной схемы является модель «сущность — связь». Под сущность понимают основное содержание объекта ПО, о котором собирают информацию. Экземпляр сущности – конкретный объект. Например: Сущность – факультет, экземпляр сущности – Факультет математики и информационных технологий.

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

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

Рассмотрим концептуальную схему БД «Документооборот кафедры» (рис.1.1) (в данной схеме не будем указывать атрибуты).

Тип документации

Должность

Рис.1.1. Концептуальная модель «сущность – связь» для БД «Документооборот кафедры »

Источник

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

4.1. Определение предметной области

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

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

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

4.2. Анализ предметной области (анализ осуществимости, бизнес — моделирование)

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

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

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

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

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

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

Анализ осуществимости

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

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

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

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

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

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

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

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

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

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

1. Каковы основные понятия предметной области, их определения и взаимосвязи? Результат можно оформить в виде глоссария и/или концептуально-семантической модели предметной области.
2. На основании каких правил — международных, федеральных, муниципальных, районных и т.д. законов, указов, стандартов, спецификаций, регламентов и т.д. — происходит то, что происходит в предметной области? Результат оформляете в виде структурированного списка или прикрепляете к элементам концептуальной модели.
3. Что реально (какие процессы, события, факты) происходит и в какой последовательности, взаимосвязи? Результат оформляете в виде сценариев описания бизнес-процессов (что достаточно универсально) или диаграмм SADT ( IDEF0 , IDEF3, 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), также возможно их диаграммное представление средствами диаграмм потока работ (IDEF3), 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 ).

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

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

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

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

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

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

4.3. Формирование и документирование требований к проекту

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

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

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

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

Источник