Что представляет проектная матрица
Проектная матрица – простое представление планирующего и организационного фрейма, обеспечиваемого подсистемами и ООА (Объектно-ориентированный анализ). В проектной матрице каждая строка – этап в методе ООА и каждый столбец – подсистема. Ячейки, которые образуются пересечением строк и столбцов, представляют собой отдельные модули работы,которую необходимо выполнить. В результате Вы можете связать некоторые информационные сведения с каждой данной рамкой:
- сотрудники, определённые для выполнения работы, представленной ячейкой;
- рабочие продукты, которые должны быть созданы как результат выполнения работы;
- предполагаемые трудозатраты, требуемые для выполнения работы;
- текущее состояние работы: завершена, выполняется, будет проделана;
- ожидаемые даты начала и конца работы;
- трудозатраты, которые действительно потребовались для выполнения работы.
Вследствии того, что матрица обеспечивает компактный и интегрированный просмотр планов и состояния проекта, многие проекты поддерживают на доске или плакате образец проектной матрицы большого размера, полностью аннотированный вышеупомянутой информацией для хранения всех проделанных на сегодняшний день разработок.
Деятельность при анализе
ООА (объектно ориентированный анализ) является процессом, состоящим из анализационной деятельности, которая требуется для обеспечения формализованных моделей. Процесс описывается во фрейме, данном проектной матрицей.
Строка информационной модели. Работа, связанная с рамкой в строке информационной модели, подразделяется на несколько отчётливых видов деятельности:
- исследование;
- разработка модели;
- интеграция;
- просмотр.
Исследование. Первая задача, перед необходимостью решения которой поставлен аналитик, – собрать и усвоить подходящую информацию о реальном (или гипотетическом) мире для анализа. Многое из такой информации может быть доступно в документах как в общих работах, имеющихся в библиотеках, так и в специализированных, созданных организацией заказчика: в руководстве по производству и в руководящих принципах, инженерных чертежах и документах, бланках данных, фотографиях, обучающих материалах и т.п. Возможно, что дополнительную информацию необходимо будет получить прямо от представителей организации заказчика, людей, которые, как ожидается, будут операторами системы, и различных экспертов предметной области.
На протяжении этапа исследования аналитик может легко стать жертвой переизбытка информации, лишь малая часть которой существенна для анализа. Мы считаем, что наиболее эффективным подходом при рассмотрении этого является классическая инженерная запись: короткое связанное с одной темой техническое замечание или записка. Для усвоения и сжатого выражения информации, которую необходимо рассмотреть для построения информационной модели, записывают каждую беседу или совокупность относящихся к делу добытых из документов сведений в техническом замечании.
Разработка модели. Как только вы хорошо разобрались с предметной областью, может начинаться работа над созданием формализованных моделей.Начните с эскизной зарисовки первого проекта графической информационной модели. Заполниет её атрибутами и связями, предложенными техническими замечаниями.
Как только у вас будет довольно законченный проект графической информационной модели, начните подготовку описаний атрибутов и объектов. Эта деятельность может потребовать решений дополнительных вопросов. Продолжите совершенствование модели и исследование вопросов по мере их возникновения до тех пор, пока не выясните все подробности.
Часто бывает так, что некоторые фундаментальные вопросы не могут быть рассмотрены достаточно быстро, поскольку зависят от решений, которые ещё предстоит принять заказчику или другому отделу в вашей организации. В этом случае у вас есть возможность приостанавливать работу над частной подсистемой до тех пор, пока не будут получены ответы. Альтернативно наилучший выход может быть в том, чтобы продолжать, готовя техническое замечание, документирующее опции. В дальнейшем выберите одну из опций, зафиксируйте ваш выбор как предположение в документе, озаглавленном “Контекст для просмотра подсистемы” и продолжите анализ. Несмотря на то, что эта стратегия несёт с собой риск, связанный с возможной необходимостью переработки части анализа, она, вероятно, облегчит процесс принятия решений, так как законченный анализ обнаружит любые вовлечения опций, которые вы выбрали для исследования, и может пролить некоторый свет на другие опции.
Интеграция.Как только работа над информационной моделью и связанными с ней текстовыми документами закончена, постройте (или модифицируйте) модель связей подсистем для домена, в котором подсистема содержится.
Просмотр. Вследствии того, что информационная модель – основа для всего анализа и проектирования – ещё создаётся, мы проводим детализированный технический просмотр работы в этой точке. При этом мы преследуем две цели: проверить, что существенные аспекты реального мира были точно сохранены в формальных моделях, и проконтролировать соответствие модели правилам ООА, которые состоят в том, что каждый объект имеет идентификатор, все связи формализованы и описаны и т.д. Команда для просмотра должна, следовательно, включать как экспертов предметной области (для обеспечения первой цели), так и экспертов по моделированию (для второй). Если вы не можете предоставить экспертов предметной области для просмотра, замените их аналитиками, не работавшими над этой частной моделью. Снабдите аналитиков-рецензентов техническими замечаниями, которые могут в дальнейшем использоваться как описание действительности, с которой сверяется модель.
Строка моделей состояний. Деятельность, связанная с рамкой в строке моделей состояний, – это разработка модели, вериикация взаимных действий, интеграция и просмотр.
Разработка модели. Начните работу с моделью состояний эскизной зарисовкой грубой модели взаимодействия объектов для установления иерархического представления объектов. Затем формируйте одну за другой модели состояний и накапливайте в процессе работы список событий. Может быть, будет необходимо провести некоторые дополнительные исследования, чтобы определить тонкости поведения различных объектов.В таком случае запишите полученные сведения в технические замечания.
В процессе построения моделей состояний вы будете, вероятно, идентифицировать некоторые дополнительные атрибуты, которые должны быть добавлены к информационной модели. Чтобы не выполнять лишнюю работу, сохраните список этих модификаций и обновите информационную модель всю сразу, когда модели состояний будут закончены.
Чтобы сделать более ясной корелляцию информационной модели с моделями состояний, многие аналитики используют возможность видоизменения планировки информационной модели, чтобы она соответствовала планировке модели взаимодействия объектов.
Верификация взаимных действий. Если взаимные действия между моделями состояний нелегко понять из ДПС и единственной модели взаимодействия объектов, проиграйте взаимные действия, используя автоматизированный имитатор или ручную процедуру. Альтернативно опишите взаимные действия на схеме каналов управления. В любом случае подготовьтесь для объяснения взаимных действий различных моделей состояний в просмотре для этой ячейки.
Интеграция. Как только модели состояний и модель взаимодействия объектов завершены, сформируйте (или модифицируйте) модель взаимодействия подсистем для этого домена.
Просмотр. При рассмотрении рабочих продуктов ячейки в строке моделей состояний, в равной степени особое значение придают оценке того, правильно или нет отображено действие реального мира, и верификации непротиворечивости моделей состояний, модели взаимодействия объектов и модели взаимодействия подсистем.
Строка моделей процессов. Работа, связанная с рамкой в строке моделей процессов, требует трёх видов деятельности: разработки модели с последующей интеграцией и обзором. Эта работа вполне простая и обычно выполняется очень быстро.
Разработка модели и интеграция. Разделите работу так, чтобы каждый аналитик отвечал за создания ДПДД* для некоторого количества моделей состояний. Во время этой работы каждый аналитик может поддерживать отдельную таблицу процессов состояний. Когда ДПДД* закончены, объедените отдельные таблицы процессов состояний и устраните все расхождения в именах и идентификаторах процессов. Затем создайте модель доступа к объектам для подсистемы и модифицируйте модель доступа к подсистемам для всего домена.
Просмотр. Просмотрдля рамки моделей процессов даёт возможность убедиться в том, что действия моделей состояний точно отображены на ДПДД*. Поскольку никакой новой информации по предметной области на этом этапе не поступает, верификация лучше всего выполняется аналитиками.
—
* ДПДД – Action data flow diagram – диаграмма потоков данных действий.
—
Источник: Объектно-ориентированный анализ: моделирование мира в состояниях.
Авторы: Салли Шлеер, Стефан Меллор
Книга издана в 1993-м году, на счёт переизданий – не в курсе; посвяцена изложению самых первых этапов процесса разработки сложных (программных, технических и других) систем.
