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

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

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

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

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

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

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

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

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

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

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

12.В каких отношениях состоят понятия Анализ предметной области и Бизнес-моделирование?

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

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

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

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

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

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

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

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

13. Что лежит в основе схемы Захмана?

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

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

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

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

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

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

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

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 - в зависимости от личностей и командных традиций, интересы в скорейшей разработке "на результат", как можно более долгой разработке "потому что нравится процесс" или чтобы сохранить работу, как можно более качественных артефактах "чтобы потом было легко поддерживать" или чтобы "забыть как страшный сон", или не слишком качественных артефактах, чтобы поддерживая их, сохранять работу; баланс существующих и новых технологий; баланс повторного использования и разработки заново

* Команда n

* Компания-дистрибьютор

* Инвестор - аналогично

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

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

* Компания-кастомизатор

* Инвестор - аналогично

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

* Команда n

* Компания-интегратор

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

* Компания-заказчик

* Владелец решения

* Бизнес-подразделение 1

* Руководитель

* Исполнитель - роль 1

* Исполнитель - роль n

* Бизнес-подразделение n

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

* По степени доверия

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

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

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

* FOSS

* Поставка As Is

* SLA

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