КаБа

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

Чтобы нагнать прозрачности к предыдущей записи , приведу пример моделирования контекста из своей вполне реальной жизни. Тем более, что мне все равно его надо продумать. Итак, постановка задачи следующая: Необходимо организовать контроль нескольких проектов, разделенных на три группы. Над каждой группой стоит выделенный менеджер, который управляет проектами своей группы. Я не лезу в техническую сторону вопроса. Мне важно лишь четко понимать, что: на текущую команду есть бюджеты текущие работы не вылетают за бюджеты и сроки команде не грозят простои У нас в настоящее время есть три системы, которые каждая по-своему закрывают вопрос планирования и управления: MS Project Система репортинга затраченного времени (назовем ее TRS) Система бюджетирования (пусть будет SBP) TRS сливает факты в SBP и посмотреть, сколько на каком бюджете осталось доступно средств, проблемы не составляет. Время в TRS репортится под таски проектного плана, импортированного из MS Project. ...

Что такое контекст В широком значении контекст - это среда, в которой существует объект. Применительно к аналитике в IT под контекстом стоит понимать модель, определяющую среду, условия функционирования и границы проектируемого приложения, а именно: ключевую функциональность приложения; ключевых пользователей (группы пользователей) приложения, смысл их работы с приложением; смежные приложения и основные идеи взаимодействия с ними; аппаратное, информационное, организационное обеспечение, создающее инфраструктуру работы приложения (если все это дело имеет явное влияние на проектируемое приложение); любые другие условия и условности, которые, на твой взгляд, влияют на проектируемое приложение. Контекст позволяет: понять функциональные границы проектируемого решения; получить представление о смежных системах и принципах взаимодействия с ними; выделить ключевых пользователей / группы пользователей и определить их основные потребности; определить ограничения, связанные ...

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